Automation Anywhere (AA) Review

While the platform is feature-rich and easy to use, it is the skill of the coder that determines how well the platform is leveraged


What is our primary use case?

Most of our automation happens on Automation Anywhere. 

While the automation is being done, we use it as a platform. Then, depending on the number of users needed, we apply the corresponding licenses.

The good thing about Automation Anywhere is that any process, which is repetitive, rule-based, and only requires you to do the coding onscreen can be automated. Therefore, Automation Anywhere makes for a good use case. Wherever the process is rule-based and deterministic, with no decisions to be made, you can use it. 

It can automate any processes where the process is well established, standard, or stable, and there are not many changes in the process. For example, a simple task, such as logging into a website, launching a website and doing systematic sketch on the website, can easily be captured to Automation Anywhere. In some cases, you are doing processes which require you to log into a website and connect information or fill in information. This is pretty much doable. I see lot of applications, especially in finance and accounting domain.

You might have a lot of steps where you need to either extract data, repeat data, or collect data. All of those processes can be automated through RPA, and especially Automation Anywhere. You can use even automation from the server side, not just websites. The only constraint is that the process should not require human intervention and decision making.

How has it helped my organization?

We see the application applied in the BPO space, or even in health care, in terms of claim processing. E.g., if you're doing invoice processing where the entire process is manual, and the worker has to go through the invoice to determine if a discount on the payment can be made or a penalty should be levied. In some cases, you can scan this information through an OCR, which is an optical character recognition tool. Then, the rest of the information can be pretty much retrieved by the RPA, which means the RPA will scan the information to classify this information and fill up the form. This will be sent to the ERP. This is how the workflow should look like. Wherever you can put in a rule-based system, you can automate all of the processes. In our company, all these processes are manual and you might have 50 to 60 people supporting this process. You can automate it and almost reduce a manual effort by almost 40 to 50 percent, depending upon how many techs are enrolled and what is the effort being spent in order to transition volumes.

I have been familiar with a couple of projects where this was implemented in cash applications or invoice processing, and they could automate these steps. So, I'm familiar with some of the back-end processes and where they are getting automated.

What is most valuable?

You don't have to really code anything, so it gives you a good interface, because the components are already preconfigured to have to just a drag and drop sequence in terms of how you want to take the steps. 

There are preconfigured APIs that can be used. E.g., if you want to interact with the mailbox solution, you can have the RPA fetch attachments or email body from the mail solution. You can process attachments via test file or PDF. You can even make Automation Anywhere work around PDF, which is typically not that easy to work with in terms of extracting information.

One of the features, which we have not used too much, but available, is the MetaBot feature. These preconfigured solutions are easily downloadable, and you can just plug-and-play with a bit of customization, which also means you do not have to keep recreating and can reuse existing functionality. Some of the typical uses are that you could be regularly logging into a website. You can just download a MetaBot, as a useful webpage interface and just run it. All you have to do is maybe replace the name of the website, and in case there is a certain authentication mechanism that is being used, then provide that information.

There are multiple levels of cloning. In case screen cloning doesn't work, you can do object-based cloning or keystroke-level cloning, depending upon what parameters are available to you and what is the level of information that you capture. You can traverse between object cloning, which is the lowest form of cloning to a stroke-based cloning, which is like taking care of each keystroke-level which is made by the agent.

What needs improvement?

When you are making a code, and there is a happy path and exception management mechanism, it would be nice if there was feedback in terms of whether this is the most appropriate way to hold this. I'm not sure how this can be done, but that could be very insightful. It already gives you some screen tips, but this could be done in a better fashion, in case you are creating the workflow and then you believe a beta workflow is available or could be done. If a screen tip could be given to the coder for this sort of workflow, this would be a much better feature for Automation Anywhere. 

I've realized that sometimes when screen-level cloning is a better option, people still use object-based cloning. It would be useful if Automation Anyone could give you tips recommending fewer steps or fewer areas of exception management after you inputted your code. I'm not really sure if this is doable from a technical standpoint.

It could be a bit more intuitive. It is easy to use, but I realize the workflow that you create might not be the most optimal. It would be very helpful if it could easily give a suggestion where you could try and do it this way with some sort of that functionality. This might be useful.

There are two models: the run model and the control model. In terms of scheduling and triggering, they could make it a bit more helpful and provide suggestions, e.g., if you are scheduling it for this, and there is a conflict, can you resolve it this way. Maybe you can get an upfront notification or something to that effect. 

When you bot breaks down, is there any of mechanisms or notifications that can be given? There is something coded right now where you can possibly choose to notify people, but this could be made more robust because typically in organizations people are pretty much adverse to automation. If something breaks down, they will only know at the earliest given opportunity that something is breaking down and piling up. They want to be able to resolve it quickly. If the resolution is resolution is going to take time, they want to be able to make some specific mechanism work. Immediately the fall back mechanism should work too. If there could be information in terms of tell you when the process was out of range and somebody might need to take a look at what has happened. This is because most of these responses that get automated are critical in nature and might have financial impact. People need to know that there are working fine and not broken down. It can really create an impact if they break down and nobody knows.

My experience has been that if the person who codes the bot is not very well-trained, then they might create unstable bots. So, it's not the platform. It is just how somebody has coded the bots which can bring lot of instability to them. I recommend that when you are using a coder that the person well-trained and have a good amount of experience already working on bots. They shouldn't be newbie or beginner who comes in to code because that will impact the quality of the code itself.

For how long have I used the solution?

I have been working with Automation Anywhere for the last three years at two different companies.

What do I think about the stability of the solution?

They require the process to be stable and very well-documented. They also require that anytime a change is made to the process or subprocess that the RPA gets updated. Typically, the entire process of automation might take some time, then by that time, the initial automation process might have changed a bit. There could variations in terms of volume or in the process itself.

The most important thing is that before you automate something that you must make sure that it is stable in its steady state for whatever changes might be upcoming over the next six month to year. Otherwise, you might create a bot, which will go into production, and once you realize that the process has entirely changed, then it will fail.

If there is no changes in the process, bots are pretty much stable and they have been well coded. In case there have been any changes anywhere in the process or subprocess, the bot can fail. This means you must have a review mechanism with strategy checks. Once you put a bot into production, you have to monitor it and do vanity checks. You must have a review mechanism. Otherwise, you could have situations where bots have failed and you might not know, then the process comes to a standstill.

What do I think about the scalability of the solution?

Scalability is just scaling up the number of bots, so scalability is not a problem. You can increase the number of machines and number of bots to scale up the solution, but it can be sometimes very cost prohibitive. E.g., typically, it requires a dedicated machine, and it can't be a shared environment. This can be a bit of a constraint in terms of the number of machines being used. Otherwise, the solution is completely scalable. In case the process requires more throughput, you can just increase the number of bots which are working. Also, if you are doing this properly, then you have to make sure that there are not multiple bots running at the same time which might be at cross purposes.

How are customer service and technical support?

I don't interact with the people from Automation Anywhere.

How was the initial setup?

Procurement of the license is easy, but depending upon what you want to automate and how you automate it that might take time. Setup is not at all difficult. You just take the license and install it on the application, then it's ready to go. However, in terms of what you're trying to automate, how you're trying to automate it, and the complexity of the problem, the entire automation process can take time.

The time frame to implement depends on the complexities and number of the processes and subprocesses. In a typical process, the coding, testing, and deployment could range from a week to four weeks. However, I have seen it sometimes take longer because you have to continuously keep checking and testing it. Every time the code breaks down, you have to possibly start from the beginning.

My experience has been one to four weeks as the ideal time frame. However, living and learn how well the process was understood and documented, there can be certain gaps which would only become evident during the testing phase, not otherwise.

Depending on the number of bots that you have to create and the number of the complex processes along with the given budget and timelines that you have in mind, the number of developers range from one to multiple developers. The resources that you really need are developers because they are people who will be coding. Otherwise, from an ownership standpoint, we need some subject-matter expertise for the process. The people who are subject-matter experts will be needed on a part-time basis for the developer to be able to map the process well and be able to create their technical design. Also, the SMEs will be dependent upon the number of processes and complexity. It could be from one to multiple people. Then, you will need a technical master who creates the technical documentation of how it will be coded. The number of technical masters again depends upon the processes and complexity along with the corresponding number of developers.

The deployment team may not be very big. You need just the developers and a design architect, mostly two people. All the other people come and go per the requirement stage of the deployment. There might be people who are there only for consultation. Some people might be there only to approve the solution. Whenever you bring in automation, it has to be reviewed, monitored, and assessed from the organization's standpoint. There might be people who are just doing approvals for this process deployment in case it's a very complex project, and then there is a project manager. Otherwise, sometimes the technical design person doubles up as a project manager too.

What about the implementation team?

Before implementing, you do the assessment of why the organization wants to automate: 

  • What do they want to automate? 
  • What are their objectives of automation? 
  • Is it a process optimization or is it cost cutting? 
  • Why does the organization want to automate? 
  • Who is driving the automation? Is it client-driven or is it vendor-driven? 
  • What are all key objectives with this automation?

Then, you have to build the business case in terms of what you want to try to automate. E.g., how much can actually be automated? That assessment should be done. Even the cost and time of automation versus that benefits that you're going to get out of it needs to be done.

When we start automating, we do a process desegregation. This means whatever processes are under scope that we try and understand the task level, activity level, and precedence. We make activity diagrams, then try and assess out of all of these which one can be automated. So, if the automation index is pretty high, which means that most of the process can be automated, e.g., up to 80 percent, then it might make a better business case than if the automobility is only say 30 to 40 percent. Then, the cost of automation might be way higher.

It is also important to set the right expectations with the organization. Are they new to automation or do they some prior experience with automation? Because this helps us set the right expectations in terms of the benefits which can be had. The customer might also want to understand what are the impacts if automation fails and the fallback mechanisms. For example:

  • How do you mitigate or remediate the impact of automation failure? 
  • What is a criticality of the process you're automating? 
  • What are your points of failure and choke points? 
  • What are your backup plans if things aren't going well?

The most important thing is the business case as to the cost versus the benefits of automation.

Also, are any legal or compliance regulations which are applicable because technically it might be feasible to automate, but legally or from a compliance point of view, it might not be good idea to automate. You might want to still have human intervention in terms of verification and validation.

From a financial impact standpoint, things that require a bit of background investigation might be better kept as a manual process or require a human approval rather than automating it.

What was our ROI?

It all depends on the scale. In one project that I've worked on, we had a savings of $200,000 over a three-year period. The typical ratio is that one bot will replace two people.

What's my experience with pricing, setup cost, and licensing?

One of the components of key drivers for us to renew our contract is AI or automation. As an organization, we are moving toward smaller operations.

Our pricing a year ago was $600 per license, but I am not sure of our current licensing.

Additional costs will be for the machines and the number of machines that you are using. You can deploy virtually as well as on physical machines. In both the situations, you do need to allocate a certain budget for securing the machines and where the software will be installed and running. The machines cannot be used for anything else, because only a certain bot can run at a certain time. You need to be very particular about your scheduling of running the bots, and while the bot is running nobody can use the machine. You cannot have an agent working on a machine and the bot running in the background. It has to be completely dedicated. Then there are the network bandwidth requirements and space requirements, which are additional costs apart from the licensing and software costs. The developer is also going to charge you for their coding time too.

Which other solutions did I evaluate?

There are two or three more tools in the market, but I think the preference was given to Automation Anywhere.

I have only worked with Automation Anywhere.

Understand why you are choosing Automation Anywhere, as the platforms are pretty on the same level except for certain functionalities. Also, in some scenarios, one platform could be better than another. Pick a platform and stick with it.

What other advice do I have?

It is easy to use, but I realize that the effectiveness of the platform depends on the coder and how he is doing the coding. This is my experience, because I have seen that the quality of the automation is as good as the person who is using it. In Automation Anywhere, the skill set of the coder really determines how good the automation is, which is why I am making it a seven (out of 10), not 10 (out of 10). Because while the platform is feature-rich and easy to use, it is the skill of the coder that determines how well the platform is leveraged.

I'm now mainly driving AI at my company. RPA has become a bit secondary in the sense that it is a part of my solution, but most of the time, it is AI-driven. RPA sort of helps in the execution of some of the components of that overall solution. From the organization's standpoint, automation is already a part of all our solutions. E.g., our organization is moving toward automation where almost 30 percent of any deal will be allocated to automation. It will be a ratio of 70:30, where out of $100, a total of $30 dollars will be allocated toward automation and AI.

I did my certification on version 10.4.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Try It For Yourself

Choose a 30 Day Free Trial or Schedule a Live Demo

Add a Comment
Guest
Sign Up with Email