What is our primary use case?
We are currently working on a vendor bill reconciliation process. It is in production now. We are also working on an incident management process for customer service. Within the customer services, there are four or five different processes that we are working on. All of them are incident management but for different categories at different levels. The next use case that we will be working on is bank reconciliation, and then we are planning to expand into HR for onboarding and recruitment. These are unattended robots.
How has it helped my organization?
We are able to integrate it with other products through APIs, which we may not have thought about. For example, there are some in-house solutions that we have for which we have built APIs, and we're able to integrate those APIs with Automation Anywhere. We didn't expect that we'll be working on that but it happened.
What is most valuable?
The ease of use for the end user and the very low complexity in trying to build a bot are the big factors for us. We are able to work on a project, identify a use case, come up with a design spec, and execute and build a bot within a span of six to eight weeks. In nine to ten weeks, we are able to go live, which reduced complexity. Once we go live, the user interface and the user experience are extremely good.
What needs improvement?
Their bot runners could be made to handle multiple payloads at the same time because if I want to run multiple parallel operations, the number of bot runners that I have to buy just keeps increasing. It is adding to the cost. However, there is a possibility that we don't need that many bot runners, and we can run multiple operations in a bot runner. This would be a great addition to have.
For how long have I used the solution?
I have been using this solution for six months.
What do I think about the stability of the solution?
You get what you paid for. What it says on the tin is what you'll get inside. As a customer, you will not be disappointed. If you're thinking that you want to build rockets using Automation Anywhere, then you will be disappointed. As long as you know your business needs, the automation that you want to focus on, and you understand the product's functionalities in a good way, you will not be disappointed.
What do I think about the scalability of the solution?
Scalability depends on how many parallel processes you want to run. A bot runner basically runs a bot. How many bots can it run? How many of these need to run in serial? How many of these need to run in parallel? This information will determine how much you have to scale. Now, if you're willing to pay a lot of money and have multiple bot runners, that means for each and every bot runner, you can have multiple processes running at the same time. So, if you are willing to pay, yes, you can scale. It depends on your budget. The product works whether you're on 1 bot or 20 bots. The product just goes off and does its thing. That's not a problem.
If it is 1 bot that you're running once a day at 10:00 in the morning, then you need one bot runner. If you have 20 processes that you're automating and these 20 things have to run throughout the day at different points in time at 10:00, 12:00, or 2:00, you can still run them with one bot runner. In those use cases, scalability is not a problem. Scalability becomes an issue when you have multiple processes. If a reconciliation process needs to run along with the general ledger balancing, month-end closing, and everything else, and all of them need to run at the same time, then you're looking at about 10 bot runners running 10 different bots at the same time. If you're willing to pay, you can get what you want, but it becomes a very expensive affair.
We have 15 to 20 people who are touching the application for various purposes. We have business analysts, developers, testers, and the external implementation team. We also have business users.
Which solution did I use previously and why did I switch?
I have used both UiPath and BluePrism in my previous organizations. Automation Anywhere gives me the flexibility for both on-prem and SaaS, and the difference is not huge for me in terms of performance, security, and all that stuff. It gives me the flexibility, but honestly, on paper, all these three products pretty much do the same. There is a plus or minus 5% difference here or there, but you'll not go wrong with any of these products.
How was the initial setup?
The initial setup was very straightforward. There are specific things that they ask in terms of the environments that we need to build in our typical Windows server, that is, what kind of memory and what kind of processing capability we require. I can't talk from the SaaS perspective because we have an on-prem deployment, but giving on-prem equipment based on the defined specs is pretty much child's play. There is nothing complex about it. It is very easy for developers who understand the platform. You can quickly roll out something and get it live, but you need to understand a lot of logic and the complexity behind the applications such as ServiceNow, Workday, Salesforce, etc.
What about the implementation team?
We started off with an implementation partner, and our experience with them was good. They had about three people in their team, and we had our business people who were giving the requirements. We also had our technology people who were basically acting as the bridge between our business people and their developers.
What was our ROI?
We are expecting a significant ROI by the end of the year.
What other advice do I have?
From a business angle, understand what is it that you need. Where do you see inefficiencies? If you're going to fix inefficiencies that are going to be fixed as part of a larger company-wide transformation program, then use the transformation program and fix those inefficiencies as part of the existing solution. If you think that that larger transformation program is not going to touch some places or if that larger transformation program will touch some of these inefficient areas but not in the near future, and you want some immediate wins, then going in for an RPA tool is a good decision.
At the end of the day, the business needs to be aligned with why you're making the decision, and where and what is your priority? What is your sense of urgency with respect to the places where you're implementing it. For example, in my office, we are working on customer service. There is a massive transformation program going on right now, but that transformation program is touching sales, marketing, finance, and all those areas. It is not touching customer service at all, but customer service has its own inefficiencies. So, we introduced automation in customer service because it's not being touched by the transformation program, and we don't want to keep waiting to gain the ROI of whatever we can get or the reduced cost we'll get from customer service. For example, if I'm going to implement a massive cloud ERP like Oracle or SAP, then I will fix the process as part of that cloud ERP implementation and not wait for a bot to be developed.
From a technical perspective or an integration perspective, use an API to directly communicate between the apps, if you can. You don't need a bot or an RPA to do what an API can do.
I would rate Automation Anywhere an eight out of ten.
Which deployment model are you using for this solution?