What is our primary use case?
I am a consultant working on RPA solutions in general. UiPath is one of the solutions that I am using.
The use cases depend on the clients. I have done automation of sending mail with invoices in it. We have used it for analyzing PDF documents, getting information out of these documents, preparing in three different languages depending on the client, and sending invoices by email.
We are also checking VAT numbers on the EU side to validate the client's VAT numbers and related data. We have automated the generation of reports out of SAP for two different managers and teams. We have also automated including specific signature images within PDF documents and sending them to the related service or email address.
We have mainly used UiPath to focus on processes related to the finance department. The targeted processes are the ones that are the most repeatable and require a lot of effort but there is no real focus and attention from the user. Because of its repeatable nature, the risk is that users do not pay attention to the process itself and make mistakes.
Generally, we do not implement end-to-end automation. The idea is not to automate an end-to-end process but to automate a part of the process that takes a lot of time and resources. That is the focus point, so it is not a matter of having an end-to-end process implemented. It may occur, but often, it is a part of the process where the focus needs to be reliability or time and resource consumption.
How has it helped my organization?
The benefit for our clients is time and reliability. They quite often see the benefits in terms of the reliability of executing the process, even reporting mistakes or errors that happen during the execution of the process. That is something quite valuable for them.
Usually, it takes our clients at least one month to realize the benefits. If the processes are executed on a daily basis, then it is quite fast, but there are processes that are triggered every month or every quarter. In that case, it will take at least a month or a quarter to see the benefits. Once it is executed, there is quite an immediate benefit. On the other hand, it takes time to analyze the process because often processes or procedures that are written are not in sync with what is executed by the user. We have to modify them. Often, by questioning the end user, you end up finding the shortcuts and implementing them, so the analysis takes more time, and the implementation takes less time.
UiPath reduces human error. That is one of the main reasons why automation is done for customers. Two main reasons for automation are reliability and resource availability.
UiPath saves time for our customers, but it is hard to know how much time it has saved because it varies from process to process. For example, the process of validating the VAT numbers on the EU website used to take two or three resources every quarter, whereas now, it is reduced to less than half an hour. These time savings are valuable, but the added value is reliability.
UiPath has not had a lot of impact on the digital transformation because the processes that are requested to be automated are already digital. The reason for automation is to speed up the process or make it more reliable. There is no real impact on the digitization of processes.
In terms of the reduction in the on-premises footprint, I am not always aware of the eventual use of the processes that I am implementing for the clients with the bots. I see that some of the bots are not used anymore because they have their own application that includes a big part of what has been automated on their side. It depends on the way they use it and how often they use it because I have bots that are running every day, and I also have bots that are running once a quarter. The ones that are running every quarter are harder to evaluate because people are not always able to see the resources released from executing those processes. Because they are executed every quarter, they are usually not measured. Our clients generally go for automation for reliability.
What is most valuable?
Specifically in the recent versions, the ability to change the interface is valuable. One of my clients had to upgrade the SAP version and move to a web-based UI. This was handled by isolating the UI interaction within the library for the targeted SAP on the client side. I upgraded that library to handle the web-based, and the bots worked fine after that without modifying anything in them. The usage of libraries is very important for me because it helps a lot in this kind of upgrade, specifically because SAP is used across the company. It is impacting a lot of different businesses within the company.
It is quite intuitive and fully handled by a visual interface. It is no big deal for me. I have been a developer in the past, and I have used Visual Basic and C#. If I need to specify something exceptional, it can be done. It is not a big deal. For me, it is very easy. There is a competitor with an open-source solution called OpenRPA, but for me, UiPath is far better and more intuitive.
What needs improvement?
There should be the ability to customize the building blocks instead of having to specify everything in every step. We should be able to combine these building blocks to make specific processes faster.
There should also be some kind of templates, similar to Power Automate. Power Automate provides templates for a specific context.
For how long have I used the solution?
I have been using UiPath for two and a half years.
What do I think about the stability of the solution?
I am absolutely satisfied with its stability.
What do I think about the scalability of the solution?
I did not have to worry about it so much because usually, my clients want to take control of their bots. They want to execute it when they want, so I have had no experience with the scalability of UiPath.
How are customer service and support?
I have not contacted their support. When I am developing, I try to make a bot quite stable. I am aware of what is happening and what it is doing, and I can notify people with logs or names of different events that are occurring during the process execution. I know exactly what is happening and where. It is quite easy and fast to diagnose and fix if there is an issue, but it is not often that I have to intervene in production. If a process is designed correctly and safely, not much intervention is required. Clients look for this kind of stability because that will save the time that they will have to spend fixing things in the production environment.
They have a UiPath Community, but I have not used it often. If there is something blocking, I go over there, but generally, I find the solution to the issues through my colleagues.
How was the initial setup?
It has always been on-premises. The setup is quite straightforward. If there is some kind of Orchestrator to be installed, it is more difficult, and it takes more time. Usually, they want to have someone internally to handle the Orchestrator. I am more focused on the bots and the triggers for these bots to be executed. I am not that often involved in the implementation of the infrastructure of UiPath for the operational side.
Bot development duration varies. It depends on the process, but it can take a few weeks to several months. I have bots that were developed in two or three weeks, and I also have bots that took at least six months because they were quite heavy and complex. Generally, it does not take longer than that because then it will not be as valuable to the clients. If it takes more than six months, it is better to have it developed in their own software.
Bot deployment is quite straightforward for most of my clients because, during development time, I take care of environment parameters. So, deployment is quite straightforward. It is a matter of deploying and pressing a button to have the package deployed. We then set parameters in config files, but it does not take a long time to have it deployed.
Bots usually do not require any maintenance, but if the source of data has been upgraded or modified or the UI has been modified, they might require some maintenance. Usually, once the process is running and every source is stable, there is no need for maintenance. When the data source changes or the infrastructure changes, such as the main server being moved or renamed, then there is a risk over there, but it is not a big deal to adapt.
Generally, two or three people might have to investigate the cause of the issue. If the issue is inside the bot, it is not a problem. One person is enough. If it is related to external data sources or infrastructure, it may take two or three people depending on the segmentation of the clients' people in their departments and services.
What's my experience with pricing, setup cost, and licensing?
I do not know about the exact price because I am not selling anything. I propose several solutions to the clients, and the client does choose one of them. If UiPath is chosen, they contact the official reseller in the country. In one case, I had the prices in front of me, and it was not expensive for the service it was providing.
What other advice do I have?
I would recommend it depending on the needs. UiPath can do a lot of things, and I have covered only 20% of UiPath functionality. Based on my experience and the needs that I had so far, UiPath has been quite valuable.
I would advise defining your use cases. That is the rule for everything. Once you have the use cases analyzed, you can specify what is needed, how you would do it, and what is the best solution to have it implemented. One thing that I am doing is that I am mixing solutions, where, for example, UiPath interacts with Python processes that I have developed. Python processes provide information in files. Web scraping is not difficult in UiPath, but it is quite heavy. In Python, it is faster to develop and use than with UiPath. It also depends on the number of iterations and resources available to execute it. It is a matter of the quality of a particular functionality in UiPath. UiPath relies on the .Net framework, and it has its own limitations. It has quite a heavy set of libraries and frameworks. It is a matter of balancing what you are expecting of it.
I would rate UiPath an eight out of ten. It is a good product. It is well-designed and well-executed.
Which deployment model are you using for this solution?
On-premises
Disclosure: My company has a business relationship with this vendor other than being a customer. Consultant