UiPath Platform Reviews

We do not directly use UiPath in our organization but we do have some use cases. One of those is sending bulletins. These are the notification emails that go to users on their birthdays, on their work anniversaries, sometimes they are sent after some sort of achievement, like if they have a baby. These notifications go via UiPath. 

The way it works is that the data is maintained within our tracking sheet, which is sometimes on SharePoint, and UiPath uses this tracking sheet to check the data in addition to the user and will cc everyone within the organization. For example, when we receive birthday emails, it goes to the person whose birthday it is on that day and cc's in everyone within the organization or within the relevant department. 

In the case of one of the clients I've worked with, they're working on a process where they need to provide students with a student visa pass. It's within Singapore and every student that has joined this institute needs to apply over a website. 5000 applications are received every year. These applications need to be manually added to the government website.

We automated this process, starting from the beginning to the end. There's a lot of interaction required. The team worked on an Excel sheet. In fact, a number of people work on these Excel sheets. With many people, there's always a chance of misleading data, as I might at one point be doing some more revision on the sheet, and someone at the other point might be doing more revisions. There is the chance that data will clash. In order to make sure that this won't happen, we came up with a SharePoint list where we could add the data, and if anyone changes anything, there's a simple and clear record of who made the changes, and what the change was.

At the same time, the bot can work on the SharePoint list as well - and there is no chance of a clash occurring. We can create a process and a number of steps that involve reading the data and extracting data from an application while swapping or extracting data between two forms. 

There's a lot of swapping. We extracted the data via the backend, via the database, and directly put that into the IC application. The processing time for this application previously was somewhere around 20 minutes. Per record now, the time has been reduced to three minutes. Previously, there were 18 people working on any particular application. Right now, there are only two bots working on this website, and they are doing work like magic. 

If we look at the development part, UiPath Studio has been great due to its ease of use and its UI. The availability of the UI store helps us understand the complete pre-hierarchy of the UI elements that's available on the browser or website. It's easy to use and it can be manipulated in the way we want it to. It allows us to do more work on the browsers. 

The integration aspect is very useful. Right now, I'm working on SharePoint and that integrates nicely with UiPath. The integration model is really, really great, and 99.9% of the time it works. While technology can fail occasionally, UiPath has a great track record. 

The ease of building automation using UiPath is quite good. The kind of projects or processes we have been able to automate has been helpful. We need to determine if it's a complex process, which is dictated by the number of steps. We look at the number of steps and work to determine if we can improvise and reduce the number of steps, and, if so, how. We look at if the process ever requires human intervention and where. The type of human intervention might dictate the complexity of the process, as well, for example, the number of applications we are working on. We might have to write some code on the backend or maybe we are working with an API. Everything needs to be assessed before going into an automation process.

UiPath has reduced human errors. Previously, everything was manually tracked with changes noted on the tracking sheet and we would do a copy/paste from one place to another. There was always a chance of human error. However, when this process is automated, there was zero chance for mistakes. While there may be exceptions, it would be only in rare instances the automation itself would make an error.

The product definitely reduces cost. If a company deploys automation within their organization, they need to understand that automation needs some time. One process will not necessarily reduce the cost. They need to see there will be results in the long run. It just takes time and they have to understand automation. They have to implement automation within the organization. Often, organizations will start the automation process, and then they leave it as they believe the cost is going up. They perceive this due to the fact that they need a separate system for development, a separate system for testing, and a separate system for operation, plus they need three servers for the Orchestrator. However, in the long run, automation actually lowers costs. It's just a hard up-front number to look at.

Whether or not the solution has freed an employee's time depends. If you talk about the business level, definitely not, due to the fact that, for them, it might be a burden. To the business, it might be a burden. However, if you talk to the IT department or IT level people who are working differently from users they would say that the best thing is that deployment is easy, debugging is easy, logging is very easy, and tracking is very easy. Anyone from IT can easily track how things are going. Yet, if we are talking about it from the point of view of business, for them it's not their cup of tea.

For example, if the system freezes on a person, they just close the browser, however, if the system freezes on a bot, from that moment everything must be manually re-initiated. For a regular business user, doing that process may go above their head and they may not understand how to fix it.

The Orchestrator portion can be difficult. Previously, the Orchestrator which everyone was using, was quite simple to use. However, the new one is quite complex to understand. Even with developers, they sometimes don't understand it either. 

There's a lot of things coming up that need to be learned. They need to put some more information into the academy to help others understand the Orchestrator end-to-end, especially for the new version. The previous one was quite easy. The new one is very inefficient in terms of the user interface. That's the area that I find still needs improvement.

I would suggest that they should provide a more disciplined document where users can see what exactly needs to be done in case of failure. For example, there's a very clever document on the deployment of the setup, but there's no documentation on what happens if there is a failure. Users need to be made aware of what to do if exceptions happen. 

UiPath is already aware of these exception scenarios, and when you call support they know what needs to be done. These details need to be on documents somewhere, maybe in the form of knowledge articles. That way, if someone has some issue, they can go to an article and see what's going on. 

I've used the solution for about four years now. 

Stability-wise, it's really good. When it comes to backend automation, it's amazing. With the UI automation in mind, I would say it's quite stable. However, there is a chance of errors. I would say, if you're doing a process based on a UI interaction, the stability it gives is somewhere around 5% to 10% on each process. Again, it depends on a number of things, such as the start-up package you are working with and/or what is the response of that individual. It's something that somewhat falls outside of UiPath, in terms of stability, however, when it comes to the process, everything counts. Even, for example, electricity counts. If there's system slowness or a system crash, it can affect everything, even if it's not necessarily caused by UiPath.

Attended automation has helped to scale RPA benefits. It is scalable, as, moving forward, there are multiple processes in relation to the same person, and right now it's done manually by a number of users. Probably, in the future, we can help develop a direction for that. Right now, the client is happy with what they got.

The solution is quite scalable. It's easy to scale a process or a UI. With big automation, it depends on the number of people who are going to utilize it. In those cases, we need to make sure that that network is available to scale. If you don't take into account the number of users, or if there are a lot of people using it, then the chances of failure can go up. That said, it depends on how big the organization is and what sort of licenses were bought from UiPath. 

I have not really used technical support, and therefore cannot comment. With Studio, we've had maybe a few minor interactions. It's the same with Orchestrator.

I have worked with a number of tools including Automation Anywhere, Blue Prism, WorkFusion, Kryon, and Kofax. I have knowledge of a lot of other tools. 

Kryon, for example, has a process discovery feature, and UiPath also started up with this process development. However, what Kryon provides is amazing. The way they capture everything, the way output comes, the way each step is explained with the process, et cetera, makes discovery on Kryon amazing. In comparison to UiPath, UiPath just isn't as good in this area.

WorkFusion integrates well with the part where we have to read documents, especially bot scanned reading. UiPath does not have these capabilities, as of now, on its own. You can integrate Abbyy with UiPath, however, that's a different tool altogether. With Fusion and with Kofax, these features are amazing. On top of that, their invoice capabilities are amazing. There's a vast difference between UiPath and Kofax and Fusion when it comes to reading documents. 

That said, when it comes to working on the backend automation, when it comes to working with the UI automation, UiPath stands out from the crowd. It's amazing. The way it writes, the way it provides precision handling, the way it works with the queue, et cetera, is amazing. There is no other tool on the market that offers these capabilities. 

The one feature that I believe should be better with UiPath, however, is storing data in an independent manner. With UiPath, even though you store your password on the Orchestrator with the credentials, or even with any credential manager if you get at the end of the day and somebody has not reviewed your quote, you can tell your boss to send his password in a simple text format. This is where the UiPath lacks, and this is where Blue Prism comes into the picture. It's just better at securing data. People prefer Blue Prism for this reason over UiPath. 

With my current organization, the department model is quite simple. We have three different environments for this: development, testing (what we call acuity), and production models. We have these three stages of deployment that we deploy robots and the Orchestrator based on the requirement of clients.

The deployment took a maximum of one to two hours from one machine to another machine. A complete department deployment, however, depends on the process type we are working on, as there are some features we need to develop. Apart from publishing these packages, the deployment of the server, or of the Orchestrator, or the deployment of Studio, will take a day or two to do the complete setup on one machine.

In terms of the implementation strategy, the first thing to do is the pre-checks. We need to figure out what sort of system we need. Therefore, we need to first confirm the prerequisites. Once that is done, we need to download a package and install it, and then apply the license. After all of that, we just need to create one small robot just to check that everything is working fine. There are some tools that need to be installed with that. For example, if we are working on UI automation, in that case, we need to install an extension. If we need to install the network load balancer as well, we need to install some of the prerequisite packages on the machine, on the server, to make sure that this runs smoothly.

While the licensing models are quite simple, as a developer, I don't handle details about pricing or cost.

My company does not directly partner with UiPath, however, it's a partner via a client. If anything happens with the client, it goes from my company via one of those stakeholders who take care of these things.

Currently, we use attended automation. The reason being is, it's more about password prediction, as the company does not want to store the passwords. There are a number of options that we have given to users where they can store their passwords in the credential manager. However, the company does not want to do that. The only reason we are using attended is for this, which is that the user has to manually go and insert the credentials.

I have not yet used UiPath's AI functionality in any automation programs. I have done some POCs for this, for documents in this setting. However, we've never practically implemented it within the organization.

With the current organization and with the current client we are not using Orchestrator at all. We only use attended robots and not Studio and Orchestrator. However, with other clients, we have used the cloud-based enterprise Orchestrator and have had the Orchestrator installed within the premises of the organization. I've used both.

I would rate the solution at a nine out of ten.

I am a UiPath developer and my role in the company is as an automation developer specialist. I'm working mainly in UiPath Studio, not Studio X, and I also work with Orchestrator. We are using attended automation.

We are automating the processes in our company, for example, in the finance department. One of the ones that are now automated is invoice coding determination, which no longer involves humans. At this time, 80% of our processes are completed by robots. The remaining 20% is approved by humans but I think that this will improve later. 

With respect to the ease of building automations using UiPath, from my experience, when you have a basic knowledge of programming, it is really easy for you to start your journey with the UiPath environment. You can do it without this knowledge but then, you will just need to spend a little more time learning the details.

I really like working in UiPath because the programming allows me to do whatever I want. I can declare any type of variable, I can check the locals, and I can add breakpoints whenever I need to check the states. For me, it's a very professional platform.

I really like that they offer the possibility to work with it from two sides. It can be operated from the full-programming side, as well as from the standpoint where you don't need this knowledge.

UiPath has helped to minimize our on-premises footprint, although I cannot estimate by how much because I am not responsible for that aspect.

UiPath has helped to reduce the cost of our digital transformation because it really speeds up the processes. When we compare the time it takes for a human, with perhaps a one-hour task, and it only takes 30 minutes for the robot to do it, we can see the savings. You just multiply this by the salary and we also see the reduction in cost.

UiPath has definitely reduced the number of issues arising from human error. We can confirm this with 100% certainty because we have compared it to when humans were completing processes on their own. I estimate that the error rate has been reduced by approximately 60%.

In my previous company, we managed to save about 20 FTE after our UiPath implementation. It was about two years of work. Thanks to the ease of access, as well as the fact that our employees did not require programming knowledge, we were able to show it to normal employees and explain the automation. After this, they were not afraid that they will be replaced by robots and instead, understand that they are co-working with them.

The most important part of Studio is the debugging feature. It gives you the ability to watch local variables, as well as highlight elements as it is moving through the process. The results of actions are displayed and indicate whether particular actions are performed successfully or not.

Outside of the company, I am using UiPath's AI functionality and it very much speeds up processes and improves accuracy for reading data. For example, the OCR is much better than Microsoft's solution. With UiPath, I was able to read handwriting samples but with Microsoft, I was unable to do it.

The AI functionality has allowed me to automate more processes in my own projects. It adds flexibility and improves process speed. I don't have to think about boundaries when I decide how to approach a project. 

It lacks something crucial, which is a map of the variables and arguments. When we are using a lot of variables and arguments, sometimes, we get lost. UiPath should create a map that connects different files and shows the connections between them. For example, from file A, we have variable B, and file C contains variable D. However, they are actually the same variable, but it's connected by argument and we don't know it. It is something that we have to remember explicitly. In this case, it would be really helpful for me, as a developer, to have this picture of the net. It would show me what is where and how it's connected to everything.

For the on-premises solution, if we ignore any problems that may occur with the infrastructure, such as the network, then stability is very good and the platform works well.

In my experience with cloud-based deployment, I haven't faced any problems with stability.

Scaling UiPath is really easy. When you get to the point where you have to think about scalability, you use the UiPath Installer to extend the Orchestrator by another node. There is an option for it and you don't have to know much about the network to do it on your own.

I am part of a four-person development team that is working primarily with Studio. We have approximately ten processes at the moment, and it is difficult to estimate how many employees are affected by the automation. 

The technical support is very professional and they work quickly. Usually, we are able to get responses in about two hours. Sometimes, it takes one day, but I have not faced a situation that took longer than two days.

The help from their site is also very professional, and well-described.

Overall, it is really easy to resolve errors.

Prior to UiPath, I used Selenium WebDriver. The problem with this product is that you have to know the Python programming language. You have to know everything inside Python, and there is a lot more typing. In UiPath, you have some clicking, and there is some decent orienting stuff, which you don't have to define. You already have some pieces of code that you can use, and this is a really nice feature.

I have also used Kryon RPA and the problem is that it's based on the OCR. This is something that I would never accept with an RPA tool unless the OCR is fully working. Right now, OCR is not a perfect technology and it causes many issues. UiPath allows us to use selectors, so we are able to track the exact area of the display in the program that we want to access.

The initial setup is quite easy, although we faced a few issues. With the help of the UiPath service desk, we were able to quickly fix our problems. The deployment was completed in a few hours on one machine. This included checking everything to make sure that it was working fine.

We followed the documentation provided by UiPath, as well as their guidelines.

At this time, we are using the on-premises version. In the next few months, we plan to move to the cloud environment, so we are currently planning the transition.

In my previous company, I was responsible for moving to the new version of the UiPath, with the Apollo interface in the Orchestrator. Where I am now, this was already done. So, yeah. I was responsible for this transition. Right now, in this company where I'm working currently, the UiPath setup was already done but I helped with the optimization.

With respect to upgrades, once we knew what had to be done, it took about one hour to complete. Otherwise, there is no maintenance required.

I have calculated ROI for our project and it seems that we will reach our ROI point in approximately two years, which is quite good.

Price-wise, it is not the cheapest one on the market, but it provides the fastest automation and the best training that I have ever seen for RPA, through the UiPath Academy. It's really easy to set up a new developer in this environment. Everything considered, the pricing is very good.

There are no costs in addition to the standard licensing fees.

We are currently evaluating Kryon RPA.

My advice for anyone who is implementing UiPath is to always check the documentation before you try to look for answers on the forum. Another good point is that when you have a problem, there are plenty of people in the UiPath community that can help you in a few minutes. This is the perfect solution, in this case.

From the maintenance side, you have to remember to increase your database with the scaling up of the automation because it can really slow down your process.

The biggest lesson that I have learned from using UiPath is to always create a backup copy of Orchestrator before you update it. This was a very big lesson for us because we had an issue with the installation. It is also really important to back up the related databases.

I would rate this solution an eight out of ten.

Most of the time, we work with financial services to automate financial transaction monitoring systems. We go through multiple CRM and financial systems, then query the transactions based on the KYC information. We use OCR operations, using UiPath Robot, to fetch information, such as, identification number, passport number, and their tax information. We extract this information, then validate with our financial data or transactions data to ensure that there is no fraud nor anomalies in the system. If there are any suspicious transactions or potential fraud, we do manual investigations. Those manual investigations are redirected from the robot to a human agent, then the human agent verifies the information. If there are any cost validation requests from other systems, such as Salesforce and PeopleSoft, then another bot will be triggered using UiPath Orchestrator. After that, we do the remaining processing. At the end of the processing, we use the UiPath analytics service. That analytics service uses UiPath logs, which helps us to understand how the bot is performing and how many transactions we have validated. From that, we look at how many were successfully processed and how many were manually handled, i.e., exceptions. We identify business exceptions for any transactions during the initial pre-validation stage, such as the user identification number is not valid or input data validation errors. For example, passport information must be an alphanumeric eight digit. If the bot identifies that the value is not eight digits, but four or five digits, then it is an invalid record straightaway. We can see this from the reporting and performance graphs.

We do automation for our HR processes, such as onboarding processes. On any day, there are five or six people who need to be onboarded. This is one of our standard business cases. We have a UiPath robot design using UiPath Studio and then it deploys in Orchestrator. This robot is being used by the HR admin. They can fill in the key information of the user, e.g., name, level, and their package. So, they import all this information, which includes my identity information, mobile number, email, and IDs on an Excel file, possibly along with a few other associates joining tomorrow. Once those entries are made in the Excel file, then the user can trigger a robot. They also need to keep the file in a designated folder. The robot will read the file from the designated folder. Then, one by one, it will read the records or line items from Excel and open an SAP portal. After logging through the SAP Portal, it inputs the required employee information. After that, it will go to Microsoft Azure Active Directory to QA the user, email, and ID. It will then go to PeopleSoft to create an HR record for the salary information, leave information, and the level at which the associate is joining. At the end of this process, it will update the status to, "The associate has been registered successfully." It will then send the updated final report to HR, saying, "The processing has been completed." The bot triggers information with their newly created email ID. They can then access or receive the onboarding information. This is how it works.

Depending on the client's requirements, we use UiPath AI Center and UiPath Apps for custom requirements. Most of the time, we don't need them. There are some times that we do based on the client's requirements.

I am using UiPath Studio, UiPath Orchestrator, and UiPath Robot.

Initially, I used the on-premises deployment model. For the last two years, we have also been using the cloud deployment option, UiPath Cloud, along with the on-premises. This is based on a client's requirements.

We can use the Process Mining tool to identify opportunities. We can then design the robot using UiPath Studio. After designing it, we can deploy it, using UiPath Studio, to Orchestrator. From Orchestrator, we can manage, monitor, and upgrade all the new patches within the UiPath platform.

If we have one place where we can see the end-to-end journey of our automations, then I do not need to manage multiple licenses. I do not need to spend money and expertise hiring multiple people and training them on multiple platforms. Also, when upgrading the systems, if I have a one place where I can manage all my automations at the same time, including UI and background automations, then we can build low-code apps using UiPath Apps. Therefore, I can manage everything within one platform, which is either a UiPath Intelligent Automation platform or UiPath Cloud. This is very important. Because if I have multiple systems, then I need multiple stakeholders to manage, upgrade, and maintain them. So, we do not need to think about all the things that I am using. There is one place where I can manage everything.

It has enabled us to automate more processes overall. In the initial days, we easily automated the low hanging fruit. As our automation journey matured, we needed to automate processes using more complex methods, like AI, machine learning, and advanced OCR functionalities. 

The UiPath package available on UiPath Studio is useful. Compared to other RPA tools, like Automation Anywhere and Blue Prism, we found that this package gives us the opportunity to automate tasks in the shortest amount of time. There are multiple templates available on UiPath Studio. For example, if I need to do multi-setting processing, which means we are going to process multiple records simultaneously, we can use a UiPath Background Process as a template. Using the template, I can run multiple robots on the same system, which will not interact with other systems. It will work in the background. We have found that really valuable. This is not available with other RPA products, such as Automation Anywhere and Blue Prism. This is one of the valuable things that we have found in UiPath.

We use the UiPath recorder. For the latest, modern experience, we have a recorder called App Integrations. Using that particular recorder, I can automate tasks with multiple systems without thinking about having manual integrations between multiple browsers by identifying multiple sessions. Sessions can be used by the same recorder during the entire automation cycle. For example, I have two screens, one called PeopleSoft and another one is SAP. I can do a keystroke, mouse click, and then hit the submit button within PeopleSoft. Then, at the same time, I have another window open being used by the robot. I don't want to think about separating two windows, so the recorder takes care of this.

The UiPath recorder has multiple ways of identifying. For example, it uses UI elements, fuzzy logic, and image recognition at the same time. These three methods are used by only one recorder. Whereas, with other platforms, like Blue Prism and Automation Anywhere, I can use only one method at a time, so one command is one method for selecting or identifying objects. Whereas, with the app recorders, I can use three methods using one command. So, if one fails, another one will back up the scenario. Then, if another one also fails, the third one will help us automate. That is the ease of automation, which is a valuable feature that helps us ensure that automation works flawlessly, without having to look at if one of the methods failed.

One of the 2018 projects was built using version 18.2. We then got a report from users that it was not working. Most of the time, it failed on multiple use cases. When we took the process from the owner to repair and troubleshoot, we found that many packages were not being recognized by the new version, which is 2020. So, we had to upgrade to the latest package, then do a repair. It took a good amount of time for us to repair the package. We had to go back to the UAT environment, then do testing and get approval from the UAT. We then had to sign-off and deploy pre-production and post-production Hypercare. So, the automation cycle being repeated by almost 40% is quite costly to the business, but this is rare.

The vendor had already noticed these things were a big pain for us. With the recent versions, 2019 and onwards, the compatibility between the activity and packages is there. Prior to that, there were some issues. The UI automation package was the one that was mostly affected. Many people who were early adopters of UiPath observed or experienced these kinds of issues.

Sometimes, when we are using Remote Desktop automations, we may need to use a different approach along with the AI functionalities. For example, if I need to recognize the object on the screen, which I cannot do using native methods, then along with the AI functionality, I may need to have a backup method, such as the OCL methods along with AI Computer Visions. This ensures that it works robustly and my solutions deliver 100% results without any manual intervention. In such complex scenarios, we are using AI features along with multiple methods for the backing up of the AI features. We have to ensure that if something goes wrong with the AI features then we have another method which will ensure, if A fails, then B will back up our solution's process as expected.

I have been using it for the past six years.

We use UiPath AI Center, UiPath AI Computer Vision functionalities, and Document Understanding. These AI features came into the picture from 2019 onwards. First, we received updates using UiPath Computer Vision functionalities. Then, we received AI Center, which was not stable in its initial days. However, during the first quarter of 2020, we received version 2, which seems to be more stable. From there, we received general availability versions with integrations on UiPath Studio and UiPath StudioX. These work much better, as compared to the initial versions. So far, all the components of UiPath Computer Vision, Document Understanding, and UiPath AI Center work well. 

I appreciate other benefits, such as UiPath community support and UiPath enterprise product support, because if anything goes wrong, we search in Google or the UiPath Forum where we can find the answer. Even if the answer is not available, and I post a question, I am quite certain that within one day that I will get someone to respond to the question. It may be someone from the forum or UiPath. Most of the time, the answers are readily available on the UiPath Forums.

UiPath Forum is the one place where we reach out to research problems, do troubleshooting, or get some help. If we need some help regarding the installations or licensing, we can create a ticket. Typically, we get a response, email notifications, or support calls within four to six hours.

We hire fresh, new graduates that we are going to train. UiPath Academies offers numerous training tutorials and certifications, which helps us to train our newly hired resources who are completely new to RPA and UiPath. So, the training is really useful in terms of video tutorial practice and configuring our multilingual environment. UiPath Academy does support English, Chinese, Malay, and German. So, our associates from multiple offices, who are already working on the global initiative, can learn the same things at the same time. Or, they can get someone from an English background.

I started RPA using UiPath.

Using the tool for the last six years, the initial setup is like having breakfast every day; it is very simple. I can do it much faster than someone new who started two years back or the new guy. I know what to do and how to do it.

Because it is software as a service, the setup and configuration time are very quick. Within an hour or two, we can set up the infrastructure deployment for a starter package. Configurations can be done smoothly. The infrastructure deployment, which typically takes a week's time, can be minimized to an hour. This saves us a lot of time and money for multiple components.

In the initial days of 2016 or 2015, our automation journey was center of excellence (COE) based most of the time. Nowadays, we changed our strategy, and it is more employee involved. So, an employee can go into UiPath Automation Hub and submit their idea. If they have time and are interested, we give them the training to use UiPath StudioX features for automation. If a process is complex based on our assessment, we pick that process and do the automation so the COE and employ-driven automation work hand in hand. 

With a simple process, then the employee can automate it and do the PoC. If they need help, we are more than happy to help them. However, we found when the processes are medium to highly complex, this is something professional developers should be working on. If they are interested, they can contribute and learn, but it's less likely that a business user would be involved in a complex automation process.

UiPath has absolutely reduced human error. Infrastructure setup and maintenance are taken care of by the product owner or vendor. So, there is 100% assurance that nothing wrong will happen in the system because they are the people who built and deployed the product. Whenever we deploy, there may be a chance that something might go wrong or configurations went wrong. For example, I need to configure the Internet information services port. If I incorrectly configured the port or use a different method, there is a high chance that I might need to redirect the port to some other router or native firewall. If I use UiPath Cloud, everything is taken care of by UiPath. I just log into assistance, then allocate the license and configure our users.

For small to medium clients, those clients have an investment of about $100,000. We see around six to eight months in, they get something around 40% to 60% ROI being returned to them. Then, within a year to 18 months, they get a 100% to 120% ROI realized.

When we implement a robotics process automation solution using UiPath, and if the client's budget is limited, we mostly encourage the automation journey to be done using UiPath Cloud. UiPath ensures that it works fluidly, performs all upgrade security patches, and has 99.9% uptime.

In the initial days, UiPath was more competitive in terms of the license pricing as compared to Blue Prism and Automation Anywhere; it was much less. Currently, the pricing is quite standard compared to the other two vendors. 

We can use UiPath Cloud, which helps us to save a lot of money and infrastructure costs, if the automation journey or project is for a small to medium-sized company. However, if it is a big company, then on-premises is preferred. 

I have also used Automation Anywhere and Blue Prism as well as open-source automation platforms, such as TagUI and Selenium.

The main pros to using UiPath are its user interface, user-friendliness, learning platform, and support.

We have been using the UiPath Apps feature for the last four or five months, so it is relatively new for us. Most of our technical people are experimenting with UiPath Apps. We have planned training sessions for business users to upskill them.

If you are starting or in your initial days, I advise you to use the UiPath community version. Try first to do a PoC with the community version, trying out the automation in UiPath Cloud for free. Once you realize that this is something good as well as understand the value of it, then you can start with the initial package. If you think that you can start big from the beginning, then go for on-premises and start a large-scale transformation. However, I would advise doing a PoC first with proper guidance from UiPath and selecting a proper implementation consulting partner who has good experience or a solid past track record of doing automation, RPA, the RPA automation journey, and the transformation journey, as a whole. Not just UiPath automations or building robots, but also transforming their project and processes as well as doing Lean Six Sigma, which is a crucial part of the transformation journey. So, you should consider all these factors for a successful automation journey.

Compared to the top three tools, I rate this solution 10 out of 10.

The primary use case is the automation of many reports, dashboards, and tables that were created manually by some of my colleagues. The tasks involve collecting information from SAP Solution Manager, manipulating some of the data based on business rules that have been implemented, and then storing the data in a specific way that can be used in the next part of the workflow. This includes using Excel and the aim is to create a PDF report that is sent to the top business line managers.

UiPath is the perfect tool to implement a solution like this, with continuous operative tasks between Microsoft native applications such as Excel, Outlook, and PowerPoint.

Before our UiPath implementation, the organization spent approximately two junior FTE on these tasks, and another 0.2 senior-level FTE in order to guide junior resources.

This process runs every day and if these tasks are executed manually, it means that two resources need to be staffed forever. At the end of the project, the organization gained a boost of two FTE saved and released, able to move on to other projects. This produced real value for the organization.

The efficiency of the process was the key success factor.

UiPath has the simplest low-code user interface that I've seen in my professional life. You simply drag and drop the activity on the flow, in a clear way, with clear names, and manipulating clear variables/arguments based on parameters. These are the key points in my humble opinion.

The library creation platform is really simple to use. Basically, it works like a normal flowchart application and once you've published packages, you can use and re-use these packages like activities in another workflow.

Last but not least, official Microsoft office integration is really useful, although all of the official integrations are very easy to use.

The UiPath Connect! and UiPath Go! communities come to our support every time we need to implement something challenging.

There are features that could be implemented on the coding side; for example, automatically assigning a unique ID for the "activity" used during the flow. As of now, if you use an activity via simple drag and drop, the activity keeps the original name. If you don't change the name of the activity manually then you will lose some information during logging. It would be useful to put a simple incremental ID on each activity, so even if you don't change the activity name, you will know where the process becomes stuck.

During the last update, the connection between robots and the Orchestrator (cloud) changed a lot. It would be a good idea to provide an easy way to use a single type of robot, regardless if it is a standard robot, floating robot, connected user, etc. Basically, have a simpler way to deploy robots in development, testing, and production environments.

I have been working with UiPath since 2017, and I plan to continue.

This product is really stable, and this is true for the on-premises deployment as well as the cloud version.

This solution is really scalable. It can be used in other organizational departments or on other robots in order to boost your automated tasks.

The vendor provides really good support; fast response time and great quality!

UiPath was my first RPA solution.

During the initial setup, care should be taken when configuring the robot connection. If you choose the "modern folder" setup then you could be struggling.

I am part of the vendor team, implementing RPA for other clients.

We have a 300% return on investment.

The price and setup costs need to be supported by a strong business case.

We evaluated Blue Prism, Automation Anywhere, WorkFusion, and Selenium (for web automation).

We primarily use UiPath for end-to-end automation. We develop both attended and unattended bots and we use the Orchestrator module, hosted in Azure.

Some of our typical use cases involve automating operations like downloading files online, analyzing and capturing details, saving them in another location, transferring them, and uploading them in other forms.

The app studio feature has increased the number of automations that we create while reducing the time it takes to create them. For example, we have a limitation when it comes to transferring files from one server to another server. However, we were able to resolve it by using a remote desktop on the UiPath server. I don't need to log into another system or another server; instead, I log in and use the remote desktop from my PC. It's really cost-efficient and it saves me a lot of time. It's superb.

UiPath helps us to implement end-to-end process automation starting with process analysis through to monitoring, and this is very important to us. Whether we are automating processes for external customers or internal purposes, there is an automation lifecycle that we follow. The end-users do not have much knowledge about automation, so we have to complete it from end-to-end.

It starts with analyzing the process to see if automation will work. We then develop it by trying to replicate what the user does manually. Once it has been developed and the functionality replicated, we test and tweak it for approximately two weeks. If everything goes well during this time, the process moves to production. In production, processes are continuously monitored.

The testing is a detailed process that involves finding the problems, then implementing error handling using try/catch statements and other methods. It is done in a continuous, agile fashion where we develop, publish, trial, error handling, monitoring, and then it starts again. When a process is pushed to production, when a change is made, it does through this lifecycle again.

How UiPath has improved the way our organization functions is clear when we look at one of our use cases. We need to have notifications about documents that describe the release of products. Our bot will start by filtering documents online using keywords, download the appropriate documents, then check to make sure that each is complete. If there is a problem then emails are automatically sent to the appropriate department.

From this point, we transfer the file into another folder and upload the current version to the release team. They will only receive what they need, rather than having to go through the document themselves. Prior to this, they needed to check it on their own and analyze everything. With this work being done by the robot, it relieves us of two person's workloads. What used to take three people to complete, is now done with one.

In terms of saving time, for our use case that involves the release documents, we save between 80 and 100 hours per week, so monthly, you can multiply that by four.

The time saved by our employees sometimes allows them to focus on higher-value work or in other cases, when we don't need the persons, we can reduce the workforce and then hire people in different roles, such as new developers. Overall, this helps us to improve our workforce. For example, we can branch into more areas, rather than do the same thing for many different customers.

With respect to employee satisfaction, if somebody loses their position then they may not be happy. However, it is important to remember at the same time that we may open a new position because of this opportunity. This allows the person to move, find new opportunities, focus on new things, and develop themselves. To me, this is a win-win because we are more focused on generating new types of business.

UiPath has definitely helped us to reduce human errors. This is a benefit to us because, before this, we used to get customers complaining quite often. However, we have reduced the complaints. We still need to have the customer complaints section but now, we have reduced it from five people to one. The robot is not 100% error-free, but it's between 90% and 99.9% error-free. With so few complaints, we don't need as many people to deal with them.

Overall, UiPath's process analysis and optimization have increased our productivity.

The most valuable feature for me is the UiPath Studio.

It helps a lot. I wouldn't really say it's code-free; however, I would say that it's 90% code-free. It's very easy to use, with most of the actions performed using the drag-and-drop interface. When you do write code, it's a very small amount of the time.

The library activities are really helpful. With the help of the library and with the help of the forums, developers can focus and it is easy to learn. It helps in terms of time-to-value.

I also find Orchestrator to be helpful. The Studio and the Orchestrator together are like your body and your soul. Without both parts, it won't function. You need to have Orchestrator to run the Studio. Right now, today, we have a problem with our Orchestrator and it's not working. I can't use Studio because it's connected and without access to my Orchestrator, I can't do anything.

The academy courses help in the process of getting employees up to speed with the solution by providing them with the fundamental knowledge and the opportunity to practice. When you start doing it, you may face errors and again, with the docs, you may gain more knowledge. When you start to use the forums, you get more knowledge, and it all helps. But, if you only rely on the forums, I would say that it would help only 60% or 70% of what you get compared to taking the academy courses. In the end, you will only get better by doing it, and then going to the forums when you have problems.

The testing and release schedule for Studio should be improved because we find that with two releases per year, one of the versions is stable and the other one is not. It would be better to focus on a single release, but make sure that it is stable. We have had problems in the past with this and we don't need any unstable versions. For example, version 20.4.2 was not stable but version 20.10.2 was very good.

Technical support and customer care are areas in need of improvement. 

We have been using UiPath for between six and seven months.

We are in Switzerland and normally, we use local support. When they cannot resolve an issue then it is transferred to the US team and we get support from them directly. In our experience, the support in Europe is not sufficient and we prefer to speak directly with the UiPath headquarters. We find that here, the people do not have enough knowledge.

We have had a lot of problems and for example, we have an issue right now where our Orchestrator doesn't work. We have had to wait about a week for the ticket to be escalated to headquarters, and because of delays like this, we are not always happy with customer care. The product is good but the technical support can improve.

We had issues where the first person tells us one thing, but a second person says that it's wrong and it needs to be done another way. Then, a third person speaks and presents another idea. This all takes a lot of time before a fourth person explains that everything is wrong and it has to be done another way. A lot of the time when you have these kinds of problems, you just have to start from scratch.

It can be frustrating because we had spent almost three weeks upgrading our system to the 20.10.2 version and now, we face the same problem. We have not been able to properly run our system for between three and four weeks.

I have not personally used another RPA solution but I have colleagues who have experience with Automation Anywhere. We primarily use UiPath but there are some developers in the company who regularly work with Automation Anywhere.

We did not switch from one product to another. Rather, they are used for different reasons. For example, I have heard that when it comes to performing file transfers, Automation Anywhere makes it quite easy and they do not have the limitations that UiPath does.

On the other hand, I feel that the AI in UiPath is doing better. We have lots of workflows and activities in UiPath and I strongly prefer it as a product.

I wouldn't say that the initial setup is complex, although when you are just beginning with a new environment, it is not that easy, either. Because it is a new thing, you will need to learn in the beginning.

We followed the guide and found that the installation was not very tough.

UiPath saves us costs, but there is more to it than that. It saves us in terms of time spent on manual tasks, but on the other hand, we pay UiPath. On yet another hand, with the money we save, we are open to new opportunities and new business.

Overall, I am very happy with the ROI.

The price of UiPath is a little bit high, although there are no costs in addition to the standard licensing fees. Overall, it is not too costly, but slightly high.

We have not yet used the AI functionality but we are trying to. We have not developed any uses cases yet but it is something that we are working on. We will be taking some courses on it first and after that, we may try some internal use cases.

We have advanced our technical knowledge by using this product. For example, we now use JSON config files, rather than using Excel.

One of the biggest lessons that we have learned is that it is nice to have a good solution design before starting development. There were times where we tried to do something one way but a problem occurred, so we had to solve it by trying different features, then testing and running it again. A lot of time is spent during this process. Now, we have learned to focus more during the design, then start to develop it.

My advice for anybody who is implementing UiPath is that it works really well in Windows, so they have to have a Windows machine if they want to start developing.

I would rate this solution an eight out of ten.

I started my RPA journey as a developer, and I first heard about UiPath as a low-code, drag-and-drop automation platform. Back then, it was very much in the beginning stages of its development. Ever since then, I've seen it evolve quite fast. I would say even faster than other RPA platforms that I've used, in just a few years.

Thinking back to when I first started using it, there are many new features and updates and it's my preferred platform for RPA.

We primarily used unattended automation, where you deploy the bots to work autonomously. This is unattended, end-to-end automation with no human in the loop, other than providing the inputs or checking the outputs.

We have several use cases, but our main one is reducing manual work. The processes that require a lot of manual input and have a lot of human error are the focus. That could be, for instance, processes that have to do with invoicing, billing, reporting, and coding, which require a lot of man-hours, are very reliant on a human being available, and are time-sensitive. Those are the ones that are on the top list to be automated.

Beyond that, I can't specifically talk about the processes that we've automated.

UiPath helps to implement end-to-end automation, although the discovery of processes, gathering requirements, and creating the design, all happen outside of UiPath. But the development, which is developing the bots, then testing and then deploying them, does happen end-to-end within UiPath.

The end-to-end development capability is important, but this is because every tool offers this and it is expected. That said, there is definitely room for improvement in that end-to-end should include process discovery. It is end-to-end, but those ends can extend further than what it currently is. In that sense, it's no different than other RPA tools.

Another way that UiPath improves the way our organization functions is that the robots can run 24/7. If you think about a human workforce, they work eight hours a day, they take days off, they get sick, they leave, and they take knowledge with them once they leave the company. But, the robots can be run non-stop 24/7, and each process can be scaled up. The same process can be run by one bot, or it can be run by 10 or 100 bots. This means that there's a lot more flexibility that the bots bring, especially for high-volume processes that perhaps even have some peaks, such as an end-of-month rush to produce invoices or meet a deadline or an end-of-financial-year crunch.

These robots have an easier time addressing and variability when it comes to volume. They really create a lot more scalability to where businesses can grow and know that they can meet the demands of the future. So, they're a lot more future-proof, whereas people are harder to rely on.

Speaking from a business perspective, it's the FTE savings. A company obviously needs to spend money on UiPath licenses and development costs, but those costs are oftentimes lower than the cost of that FTE, the full-time employee, whose work is getting automated. If you purely just think about the financial benefits, it's the lower staffing costs.

There is also the ability to free up people. This means that even if people aren't replaced and their salary isn't saved, what they can do is pivot their focus to, for instance, be a lot more customer-facing or do a lot more strategic or creative tasks that perhaps get pushed to the side because there's not a lot of time allocated towards performing them. Now, FTEs have a lot more capacity to contribute and perform tasks that still to this day cannot be automated, like creative thinking, complex decision-making on the spot, strategy, and just human interaction.

In the beginning, employees meet automation with a critical eye. They're thinking, "Well, what's going on? Why are these robots coming in? Are we going to work alongside them? How is this going to work?" But to be honest, in the end, there are winners and losers. What I mean by that is that some jobs are replaced, and that's just simply because of that FTE saving that is usually the driver to justify the cost of development. But on the flip-side, the employees that do stay and do work alongside the bots are usually a lot happier because they have to juggle a lot fewer things.

The robots are there to make people feel like people and not like robots, where they just do the same thing over and over and don't enjoy their job or don't enjoy what they do. A robot takes that away and helps people enjoy their work a lot more because they can do non-repetitive tasks. They can be a lot more customer-facing and perhaps build stronger relationships with their customers, know them better, and have more time available to work on other projects or work on other things that they may never have had the time to do.

In our organization, the robots work on multiple projects. The amount of employee time that is freed up depends on the project and what you are automating, but a pretty good estimate would be a 20% to 40% savings.

With respect to the reduction of problems related to human error, the fact of the matter is that some employees, whether you like it or not, are more error-prone. By automating a process, we were able to standardize it, and therefore, identify the cause of the human error and remove it by replacing the process with a robot that makes a more reliable judgment in terms of action. It is literally just an if-else statement. It's a lot easier to quantify and therefore it's a lot easier to evaluate, and therefore the result is a lot more reliable. Whereas with an employee, let's say the output of their work is a lot more unreliable simply because they could be working on 10 different things on the same day. There could be a deadline approaching, and the quality of work fluctuates with an employee because of it.

With a robot, you will notice that over time, in fact, the quality improves, and that's just the basic truth of RPA. It doesn't happen automatically, and it does require work. It happens because you see the results of the automation and you see areas for improvement, ultimately leading you to make adjustments. You iterate on the RPA solution and make it better over time.

Although it does not improve automatically, through a conscious effort you can be a lot more confident in the output and then be able to see unbiased results at the end of the day. Part of these results is your exception rates, which can be errors. It can be failures, whether technical in nature or decision-making business rule types of errors. Then, you can adjust your process to where it can positively improve that exception rate, and just iterate on that to where it becomes acceptable. Moreover, it's quite stable, which is not the case with the human workforce.

The automation cloud Orchestrator has its benefits and negative sides. The benefit is the fact that it's web-based. A person who has the login credentials can access it without the necessity to have something installed. The development and the monitoring of the bots are separated in UiPath, where the development happens in the Studio and the monitoring happens in the Orchestrator.

In other tools like Blue Prism, it happens in the same place. I've used both, and the Orchestrator is nice. It has a very nice UI, it's user-friendly, it has a lot of features, and I find it quite easy to use. For example, you can see all of the machines, you can see the robots, and you can schedule them. If the business wants to see a lot more across the output of the Work Queue, they can have that visibility from Orchestrator, which is great.

The downside of Orchestrator is the package deployment, which is perhaps another minus of UiPath in general. The deployment of a new package does not take a long time, but there are a lot of steps. It's not an intuitive process. If you have to release a lot of packages, which does occur, especially in the early stage of deployment, when you are releasing hotfixes, or when something goes wrong and you need to redeploy a fix really quickly to minimize business impact, it does slow you down.

I wish it would be just one or two clicks, rather than the whole importing or exporting and connecting to the desktop application and everything that accompanies it. I wish it were a lot easier. Again, it has its upsides but it's not perfect.

The best feature in UiPath is their robotic enterprise framework because that is an inbuilt processing framework for utilizing their work queues. It's plug-and-play, and already pre-built to where you don't have to start from scratch. It's enterprise-grade and ready to be used. All you need to do is populate your dispatcher, create a queue, create a performer, and you're good to go.

The highest benefit of it is that it's just there, ready to use, and you don't need to start from a blank screen. You don't have to figure out, for example, how to create an environment where the robots can check if there's anything in the queue to be worked on. The framework is already there. The other tools that I've used, like Blue Prism, don't have that built-in quite as well.

My perspective and overview are from that of a developer, and I find that the recorder feature is really good. This is because UiPath lets you record your actions on the screen. So, if you want to interact with a web-based interface, for example, then you have UiPath record your actions and then build the activities that you would need in order to replicate those actions through the robot. It makes it a lot better and although it's not perfect and it does need to be reviewed and adjusted, it speeds up development quite a bit. This is especially true when it's basic back development like populating fields and clicking buttons and navigating on a web.

Compared to other RPA tools that I have used, something that stands out to me in UiPath is that it has a very extensive library of activities. Those activities are easy to search for and use.

When you are writing code, there is a feature called IntelliSense, which autocompletes your code. More specifically, when you're typing code, if you're starting to type the name of a variable, it will show you all of the variables available and you can just click them. It's very interactive and it's reminiscent of the Microsoft Visual Studio environment, both from the UI perspective and the coding perspective. This means that developers that are familiar with Visual Studio will probably feel right at home using UiPath. It's very developer-friendly and it's geared towards appealing to existing developers.

The UiPath Academy courses definitely help in the process of bringing employees up to speed. The Academy is the go-to place for UiPath learning and I think that other RPA tools are copying this model of disseminating knowledge, being a lot more open with training, making it freely available, and providing an online classroom. These are things that UiPath has always done, and it certainly helps new developers get upskilled in RPA, and specifically with UiPath.

When it comes to ease of use, UiPath is intuitive insofar as the basic features have a low learning curve. However, if you want to take full advantage of what UiPath can do, and if organizations want to create more sophisticated automation solutions, it is more difficult. For instance, automations involving back-end access, maybe writing directly to databases such as SQL or using API, that's a steep learning curve. In fact, I think the learning curve is exponential.

If you just want to make a robot that sends an email, that's really easy to do. But, if you really want tangible benefits, like if you really want something that solves a business problem, it is a huge learning curve and it takes a while to master. Obviously, it does have that low-code requirement, but I would say that's only for entry automation projects, like proof-of-concept or something along those lines. For something that really solves a business problem, you would need code, because that just makes it a lot more robust and a lot more powerful if you can custom-code certain steps of the process.

Features for process discovery would improve the end-to-end development capabilities.

From a developer's point of view, my biggest struggle with UiPath is debugging. The debug mode in UiPath feels clunky and it is a sore spot. It feels it's hard to control the flow of the process. There are a lot of internal errors and it's not intuitive. In general, debugging is not a good experience and I don't enjoy doing it. In contrast, Blue Prism has better debugging capabilities.

Blue Prism is a little more dynamic; you can adjust variables, you can jump around the flow, and it's easier to control. With UiPath, it's a little bit of a nightmare. It becomes harder to debug the bigger your automation is, because it's quite unpredictable, and it's quite unstable. Definitely, if debugging was improved, I would say UiPath would get 11 out of 10.

Something that I noticed recently is that they have moved to paid certification for developers, whereas it used to have free certification. This is a little bit outside of the platform itself but the pain point here from my perspective is that there is a barrier to entry for new RPA developers, or ones that want to renew their certification. It has become a lot harder and that used to be a differentiator for UiPath. It had a very strong online learning offering and it offered no-charge recertification on top. This is now very similar to what other tools are doing and I see that as a negative.

My first introduction to UiPath was in early 2018 or late 2017.

The robots could be a lot more stable, which is another area for improvement. The stability issue with UiPath is a prominent one, especially in comparison to other tools like Blue Prism. I feel that there are a lot of errors that are caused by the UiPath framework, as opposed to the robot design. Sometimes it's just very unreliable and crashes unexpectedly, which creates serious issues in terms of reliability. In early deployment, it always happens that it's very late nights, and there's a lot of babysitting processes. The robots need it because you never know what's going to crash.

In comparison with other RPA tools, it is average when it comes to reliability. I would rate other tools a little bit easier to manage expectations as to what you can reasonably expect to go wrong, and what you can reasonably expect to break. With UiPath, our developers, even our experienced ones, oftentimes get errors that we've never seen in our lifetime. This is partly due to the flexibility of UiPath, with it being so easy to adapt to all types of applications and all types of environments and it being so malleable. It is one of the most versatile tools; it's industry agnostic, platform-agnostic, and tool-agnostic, but that flexibility creates a lot more room for error in the code. It means that a lot more things can break or interfere with each other, compared to other platforms that are perhaps more niche and more targeted in what they're actually trying to solve.

UiPath is definitely scalable. It is modular, where you build a workflow and that can be reused across multiple robots or multiple processes. Those processes can then be run by one, two, three, five, and 100 bots, provided that they can work concurrently in the same environment, performing the same process. It's wonderful and the scalability is uncapped. If you have licenses, then you can use them, which is great.

The only limits are how many licenses are you willing to buy, and the inherent limits of your own infrastructure and your own process. It comes down to how many robots can realistically work concurrently in the same infrastructure and in the same network without breaking it.

We have approximately 20 developers who use UiPath. We have business users, but it is difficult for me to say how many there are.

I have been in contact with technical support, and I have experienced submitting a support ticket to them. I even got on a call with them and they were very helpful. We had been having issues with automating a platform and we wanted to get their specific insight as to what was going wrong. It had to do with UiPath not being able to extract selectors from that specific interface.

I was really surprised because they spent the time to not only address my ticket and answer my questions, but also to allocate time to schedule a meeting, and really look into the platform via screen share. I was sharing the screen with them and showing them what was happening, and they really looked into it and gave it a lot of attention.

I understand they get a lot of tickets, and I really felt they provided a good answer. They responded really fast, I would say within 24 hours, and we began exchanging details through a back and forth conversation.

They provided me with the outcome that I was happy with. It was a very good experience.

In addition to UiPath, we used Blue Prism and Automation Anywhere. UiPath is king here, and I rarely hear anything about the other two. I would estimate that we use UiPath 95% of the time, perhaps even 99%.

The alternative to UiPath that I am more familiar with is Blue Prism. From my perspective, UiPath is geared towards developers. The audience towards which it's skewed is the developer or the technical person. Blue Prism is geared more towards business people. It's geared towards converting business people, including SMEs and subject matter experts that know the process well, into developers. You will find that the language that each program uses is one that's geared towards the target market. Consequently, UiPath uses a lot of developer language and developer concepts.

For example, UiPath works similarly to the Visual Studio Environment. Blue Prism, on the other hand, uses a lot of flowcharting visuals, as well as the language that it uses for the same concept. It's going to use a definition that's more from a business process flowcharting realm. Recently, both platforms are converging onto each other and I feel like they're becoming more and more similar, but they still have a few things that are different.

One thing that stands out for me is that Blue Prism has wonderful debugging. It's a lot better than UiPath, and it's an all-in-one tool where the monitoring and the building of the robots happen in one application. The deployment is also really easy.

Blue Prism also offers online learning, which is great. They didn't use to have that offering, and I think that they got a lot of inspiration from UiPath. Their online courses have been great because previously when I was learning RPA, I had to use YouTube. Now, they have a whole Blue Prism university, which is amazing.

Blue Prism has inbuilt version control and a lot of other great features. They have a heavy emphasis on security and encryption, which UiPath perhaps needs to improve on. Companies such as banks, insurance agencies, and finance agencies are a lot more interested in Blue Prism because of its very strong security protocols. The encryption offering is a key requirement for companies that work with a lot of sensitive personal data.

I have never been involved in the initial setup, although my understanding is that it's quite a journey.

The areas of the organization with the most ROI from UiPath are operations, finance, HR, and sales. Those are the key departments, although it's across every organization because those departments have a lot of manual work-intensive processes that are the first contenders for automation.

We have a yearly licensing model that gives us access to the development and production environments. The cost of licensing is expensive.

Part of automation is the analysis and optimization of processes because the analysis phase is a by-product of wanting to automate a task. If you want to automate something, you have to break it down into parts and really look at it and think, "How can I reduce this into a series of business rules, a series of decisions, or series of steps?" It's an exercise of process optimization in and of itself because a good practice in automation is to not just take what it is and automate it, but to think, "Does what is currently in place actually work? How can it be improved? How can it be streamlined? How can it be done in fewer steps?" It's a good chance to practice some process review, improvement, and transformation.

The idea is to make it optimal because the current process usually has unquestioned practices that maybe haven't been reviewed for a very long time. A lot of businesses say, "We've always done it this way," and they've never thought to revisit the approach. RPA gives you an opportunity to think about whether what you've always been doing will work when it's being done by a robot. Most often, the processes get streamlined through the requirements gathering phase, understanding the as-is, and then a key part of that is doing the process design, which is the to-be vision.

During that time, processes go through a few design iterations where they are optimized and streamlined because we want the robots to be as efficient as possible. This means performing as few steps as possible without sacrificing value and efficiency. It is important because any inefficiencies in a robot are going to scale with the number of times you're going to run that process. If you run a process a thousand times, and let's say there exists inefficiency that results in an extra minute being used, that could be shed if you were to review and optimize that process.

Ultimately, optimization is an important exercise because the benefits include a further capacity to run more automated processes, and less time is taken up by inefficient steps.

Something to be aware of is that updates to the platform have to be managed because any update could impact the performance of a bot that was built with an earlier version. To avoid having a newer version impact the performance of something that was built previously, all of the updates need to go through a due diligence process.

The biggest lesson that I have learned from UiPath is surprising; not everything needs to be automated. It feels weird to say it because thinking, "Well, I have this platform, I have these bots, why not just automate absolutely everything?", but the truth is that there are things that can be streamlined outside of RPAs. Also, some processes can be automated through other means. Consider the very simple example of sending automated emails, or sorting out your inbox by putting the right email in the right folder, those types of things can be done with email rules rather than RPA.

If a platform already has some sort of inbuilt automation, whether that's a social media platform, email platform, networking platform, or any other type of platform, it's always better to explore that first before looking to solve that problem with RPA. There are times when an Excel Macro or an email rule will be a lot faster and a lot more cost-efficient. RPA should be directed towards big-ticket items, big problems, and large volumes to where no existing solution would provide the same level of value.

My advice for anybody who is considering UiPath is to try it out for themselves. The most beautiful thing is when companies take the leap to have a very small citizen developer team, where they upskill a few technically-minded people with free courses and try to build a small proof of concept to see if RPA is the right path for them. I really encourage that sort of curiosity and experimentation because all of the resources are out there and anybody can learn, as long as they're driven and passionate and curious about automation. I would really encourage people just to give it a try and see what comes out of it.

In our organization, UiPath is the number one RPA tool. Being close to the industry as a developer, and I do feel like it's the preferred tool, at least where I'm based in Australia. It is definitely the preferred RPA solution on the market. Our usage is definitely going to increase in the future. I feel like the future is bright for UiPath. That said, it isn't perfect.

I would rate this solution a nine out of ten.

We develop and deploy use cases in the area of the cloud. We have deployed over 100 use cases. Most of our use cases are related to SAP applications, web applications, and mainframe applications.

One use case example is related to mainframe applications. The bot monitors mainframe applications 24/7. If there are any new jobs, they are identified, then the bot changes the status of the job to differentiate it. 

Previously, we are using the 2016 version of Orchestrator, then we upgraded to the 2018 version of Orchestrator. Some clients are deploying the 2020 version. It depends on the client. We suggest using a version back to clients, i.e., the 2019 version. 

We automate retail, sales, and agricultural services.

There are a bunch of candidates being monitored 24x7. Automation Cloud monitors these jobs, and whenever new docs come into the application, it will then change the status manually based upon certain conditions. Once we deploy the automation into the production, our manpower has been reduced so there are only one or two people needed for the backup. The rest will be taken care of by the automation itself. So, there has been a drastic reduction in our workforce.

We schedule different jobs using Orchestrator only. We have a separate team who takes care of jobs that we apply in Orchestrator. So, if there are any failures, it will automatically send email alerts to us. 

Within Orchestrator, there is a tab where we can restrict roles from the admin level to the user level. Developers give only access to the jobs. Whereas, admins have a roles option to restrict access.

There are still some areas that need improvements. Currently, the tool is not 100 percent accurate with hand written notes and image based automation. It is also tedious using it with Word applications. 

We are doing automation to take care of all our processes, but we still need support people 24/7 to monitor these jobs. So, human intervention is still there. We have two people monitoring these automations 24/7 because there are still some challenges with the automation.

I have been working with it for two and a half years.

When new bots are developed, we definitely see some errors in the first few days, which are usually connector issues. Once the bot is moved to production and has a lot of enhancements and patches to the automations, we make sure that the automation is running smoothly. So, during the initial stages, it won't be very stable, but after a few enhancements to adjust to the automation as time goes, then it will become stable.

Once we deploy and release the automation into production, we will monitor production to see if there are any new challenges, different scenarios, or bugs that we need to fix. We have monitored the automation after deployment for around six to seven months, and the automation went smoothly without any issues. Because the automation is performing pretty well, we have deployed it to more of our workforce and their different jobs.

We have separate, dedicated test data in three different environments. Orchestrator has a database and email server, so everything is in Orchestrator. Apart from the servers, products, and services, everything has a separate operations team, which has eight to 10 members, who take care of everything.

Previously, they used on-premises services for the bots. Then, they asked us to migrate more than 20 bots from on-premises to our AWS environment. So, we have created a dedicated AWS environment for them.

The deployment process goes this way: 

1. Developers develop the use case in a development environment. 
2. Once that is done, then they will move the code to the non-cloud environment.
3. They will test the code if the automation is running fine or not. If automation is running fine, they will show the data which is running fine as a code to the client. 
4. Once they have the desired output, then we will move to the production environment. 
5. The operations team will then deploy that process. 

The first time, it is a bit tricky. Going to production, it will take around 20 to 30 minutes to deploy the first time. If there is already existing automation, we only need a patch to implement it in production, then it will take roughly five to 10 minutes to apply.

The process of testing and deploying code takes roughly one to four nights maximum.

For deploying UiPath, we need at least three to four RPA developers. In general, one person can deploy at any time. The other two to three people are just there on support calls. 

Post-production, we have an operations team of eight to 10 members who take care of the automation.

There are some automations that save us thousands of hours monthly. These are automations that we run 24/7 as well as some automations that we run every five minutes for installing backups. Depending upon the amount of time the automation is standing, we will manage the capabilities of the server. 

To some extent, it has reduced the operations:

1. The automation is sending an email whenever there will be an error. Automatically, it is not going to the user. The user just needs to verify their emails. 
2. Whenever an error is noticed in the code, the automation will fit the address and email the operations team members. 

In these ways, it has helped to reduce operation costs, but not completely.

There are three types of licenses: unattended, attended, and developer.

We also use Automation Anywhere (version 10) and Blue Prism automation tools, but I think most clients prefer UiPath. There are more activities available in UiPath versus the Automation Anywhere version that we use. For example, UiPath has database-related activities, but Automation Anywhere, version 10, does not have this feature. I have tried using mainframe appliances in UiPath and Automation Anywhere, and I found that UiPath is more flexible and has more options available.

The solution is single sign-on, so the authentication is done for us, because it is difficult to remember all our passwords.

We have a ServiceNow ticketing tool for reporting issues related to UiPath.

UiPath is very good for developing web-based applications, especially for SAP and the web. For these two applications, you can go with UiPath without any doubts.

I would rate this solution as an eight (out of 10).

UiPath is used to automate processes, eliminating the need to increase headcount.

There was an increase in both quality and quantity while not having to increase admin simultaneously. We have successfully automated the majority of our automation projects.

The UiPath automation has helped us to keep our bottom lines down across the board.

UiPath has helped our organization with its environmental and social initiatives.

It has freed staff time for other tasks, improved their work quality, and saved hundreds of hours per month.

UiPath is the best automation solution available today. The process and task management are the most valuable features.

UiPath's Unassisted Task Mining has room for improvement.

I have been using UiPath for four years.

UiPath's stability is reliable, especially now that we've moved to the cloud.

UiPath scales well. We have not had any issues.

UiPath support has been responsive to us.

Positive

UiPath has successfully met our expectations by reducing project costs through automation, demonstrating a strong return on investment.

I would rate UiPath ten out of ten.

I have used UiPath in my last three companies.