What is our primary use case?
We're a consultancy and I am the strategic architect. I have implemented the product at 25 different client locations spanning multiple industries. Their RPA requirements range from pretty standard, bread-and-butter workflows that navigate an application and follow some business rules, to more sophisticated ones that are integrating Document Understanding and a little bit of chatbot.
I have deployed it on multiple application stacks, including out-of-the-box SAP, Oracle, Microsoft, and some specialty, third-party products like DNA, Encompass, LendingQB, and others.
How has it helped my organization?
We have helped companies reshape their resources. That's a part of the benefits. They want to put automation in place because they want to change their headcount and not have to do those rote, mundane business processes.
We have been able to show enhancements in resourcing. A very good example is that we built a process for a client who had to spend three or four days a month doing a really lousy process involving 3,000 payment transactions, every month. The robot is able to execute that workflow in a half day, so we freed up two and a half to three and a half days where he does not have to do it. To him, this was a huge lifesaver.
It has also reduced human error, for sure. That's a positive selling point. When we build workflows for our customers we include business reports and audit logs. We typically add a status flag for a record so that every record that is transacted has traceability through the audit log. We also have a status report, and that shows how many records the workflow executed, how many were successful, and how many failed. We see a range where between 65 and 90 percent of the records go straight through. That means all the business rules were met and the process was completed for those records. That shows that they're identifying a much smaller subset of errors and that they can rely on the robot to successfully complete the end-to-end transaction. And whatever is leftover requires human touch.
That changes the dynamic in operations. They don't have to concentrate on every single record, but only somewhere between 10 and 35 percent of all records may have to be handled manually. It shows them which ones had errors, the ones that did not meet the business rules, and they know which ones to concentrate on. That's a feedback loop that helps them decide if they need to add a business rule or change a business rule to get to a higher percentage of throughput.
In terms of employee time, I have documented situations where clients might have had 10 people working on half a dozen business processes. We've implemented IPA—intelligent process automation—and then they only need three or four people, so they can redeploy those other folks to other places. It saves them money because they don't have the FTE costs they had before for those processes.
What is most valuable?
From a development point of view, the Studio tool as the basis of componentized architecture has been a really critical part. You get out-of-the-box, componentized architecture to jumpstart or accelerate development and that's a very key feature.
When talking about deployment, you have a very robust infrastructure to manage your automations, the robots, and how they can be configured, deployed, executed, monitored, and maintained.
When it comes to process discovery, it has excellent front-end tools and capabilities vis-à-vis Task Capture and Automation Hub.
And at the back end, the notion of botting sites to monitor and manage your robotic infrastructure and reporting on it is pretty great. These are all pretty good tools.
The ease of use is because of the UI's capabilities. The fact that it has a .NET Framework, from a developer's point of view, makes it a very easy product to jumpstart into. But what is key is the ability to do really fine development activities. You really can get to a nuanced level of development for complicated and robust workflows. The tools are definitely well constructed to allow you that kind of flexibility.
A really good example would be if you are doing something with OCR to read a PDF. You can vary the OCR engines and test them out to determine which OCR engine will give you the best results. That's pretty good because you do get into situations where one engine may work better than another.
We can also implement end-to-end automation and that is critically important. We always strive for what I call "straight-through" processing, where we're trying to handle all the use cases based on business rules. We're not always successful, but that's not a bad thing. If we can take 60 percent of your processes and automate them with straight-through processing, where everything works, your exceptions are a much smaller work set. That has had a significant impact on clients. For one of my clients, where we have worked very hard, they have better than 90 percent "throughput," meaning that 90 percent of their transactions go completely through the automated workflows. The client has been incredibly pleased with that.
We also use the UiPath Academy all the time, in two ways. Internally, we avail ourselves of all the courses. It's especially important to understand new updates and releases. It's a great place to go to understand what those new features are. That is of real value.
But the Academy is also a good starting point when I want my engineers to be certified. They can jumpstart that process by going to the Academy and making sure they know how the product works. They follow through on that program and complete the training. Once they finish that, we try to get a project or two under their belts, and then have them take the certification exams.
What needs improvement?
One of the chief problems in all of our implementations is "application sensitivity." If an automation involves a webpage or Outlook, every item on that screen—the menu bar, the actual document, an attachment, a field—has a selector so that workflow can work correctly. UiPath does a very good job, whether for legacy systems or newer systems, of using selectors so that you can build applications that have discrete functionality.
But what happens when a selector breaks? That means that something has changed in the application. This is especially true with SaaS or third-party applications. They make one change to a field and the selector breaks and that means it has to be touched and fixed.
UiPath could do a better job of enveloping selectors to make them less fragile. There are techniques that can be used to achieve that, even without a system-related improvement, but they are not out-of-the-box. That is the one area that is the biggest pain point. It happens all the time.
They should reduce selector sensitivity and improve remediation when one does break.
I don't know how they would do it, but if the change that caused the break were a relatively minor thing, they should somehow have it automatically recalibrated. I'm sure it's a tough problem, but clients complain to me about that all the time. I have to explain to them, "Well, the application changed." They'll say, "Well, we're looking at it, we don't see anything." It's often true that you can't see it, but the selector underneath broke and that means something was done but, visually, an end user would not see it if it was a minor change. So I'd like UiPath to find a way to "desensitize" selectors.
For how long have I used the solution?
I have been using UiPath for four years.
What do I think about the stability of the solution?
It is very stable. There are no questions about that.
What do I think about the scalability of the solution?
There are absolutely no issues with scalability. We're using this with multiple clients.
The new robot polling is very helpful. We are using it effectively for clients and that technical capability is a great enhancement. The modern folder profile gets us there as well.
We're very pleased with the cloud-enabled product sets. I push that with as many clients as I can because it's the easiest to implement. On the cloud side, there were issues at one point with their licensing management, but that has finally been smoothed out and that makes life easier. If you want to add another product, as long as it gets licensed, boom, it's there. I don't have to think about it. Overall, the scalability is great.
The environments that we work in are client-driven, but they can have multiple locations and geographies. We have a couple of clients where the implementation is in the US but it is supporting Europe. And we now have a client that needs to be supported in South America. We are cloud-enabled for them and the product works great. And while it has nothing to do with UiPath, there are some latency issues over the network, so we may have to rethink how we deploy in different hemispheres. But we know that UiPath tech can support that.
How are customer service and support?
We will lean on their technical support when we have exhausted our capabilities. Most of our issues have been in the Document Understanding sphere, especially in custom model development, although sometimes there have been issues with it in out-of-the-box systems. For all of my IPA projects that include Document Understanding, I try to convince the customer to buy Premium Support, because regular support could take two to three days to finally get to the right answer. With Premium Support, I'll get it in a day or a day and a half, and that can make a big difference.
I rate their support at seven out of 10 because the initial triaging takes the longest time, and that's one of the greatest concerns for me. If you have regular support, as part of the triage process they will tell you to look at frequently asked questions, but of course, we've already done that. Overall, the FAQs are one of the weak points in the fabric of available resources. We're putting in a support ticket because we haven't found what we need. That level of support is very generic and you really have to knock hard on their door hard and say, "We've done that already. We haven't found our answer. We need to talk to an engineer." Level-one support is usually too junior, but when we get to the next level, we finally start to get better answers. Level two is good, but level one and that triaging can be painful.
We rely on the partner network, and UiPath has been an excellent partner. We do use the community as a reference point, but we don't get a lot of value from using the FAQs.
On the flip side, I have used the Community editions of all the products. That's a big plus, especially when a client doesn't want to put any money into it upfront because they're very nervous. We use the Community edition to prove the point. In that respect, the Community edition and the forums do become helpful.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
I started with Automation Anywhere in a previous job. I like both products. Both it and UiPath are excellent. Going with UiPath really had nothing to do with a problem with Automation Anywhere. When I came to my current company, they had already decided to go with UiPath. They had done a few projects with UiPath and that set the tone going forward.
As a consultant in a global practice, I do have a couple of Automation Anywhere projects going on. I also have a project that is using Power Automate.
Our preferred IPA solution is UiPath, but clients drive that decision. I had one client who said, out of the gate, "No. We're using Automation Anywhere. No questions asked." And I said, "Alright. It's a good product."
But as a company, we lean toward UiPath as a starting point and they've been an excellent partner, and I say that wholeheartedly.
How was the initial setup?
Deploying the solution is straightforward. It involves a low level of complexity and less effort.
I have a separate DevOps team that actually does the build-out of the environment. They're separate from the developer team. DevOps does the implementation. They'll talk to the client's IT department directly and work on all the details of setting up the infrastructure and they'll get it ready for us. Then the developers take over.
What about the implementation team?
We do lean on UiPath support in some niche issues areas, but for the most part, my engineers are pretty well qualified.
What was our ROI?
In terms of the solution's AI functionality, such as Document Understanding and chatbots, we no longer advertise ourselves as doing RPA. We advertise ourselves as an IPA shop—intelligent process automation. The focal point of that is Document Understanding and the DRUID AI Chatbot capabilities. We're getting an awful lot of Document Understanding projects and we use our sandbox to pump our clients' data into the Document Understanding frameworks and intelligent form factors to prove that the solution works. We really want to go for the bigger ticket items that require Document Understanding.
When dealing with Document Understanding, we are introducing a new capability to the client. We train them on how to use the tool. That is a definite change in the client's skill sets and it does pay for itself in the long run. There is a delicate balance. The investment cost is always the tricky part, but once clients start seeing their data coming through automatically, the light bulb comes on.
What's my experience with pricing, setup cost, and licensing?
Since UiPath became a publicly traded company, the flexibility and variability on pricing have really gone down a lot. It's tougher to get a better deal out of them. I'm not saying it can't happen, but as a publicly traded company, they're not the same company that they were when they were private and first growing. It's understandable. They have stockholders to answer to.
Which other solutions did I evaluate?
The top vendors are
- UiPath
- Automation Anywhere
- Blue Prism (which we don't do a lot of work in)
- Power Automate, only because it's Microsoft.
I encourage people to look at the review and evaluation sites to help them start getting an idea of what is available. Then I say, "Here is some actual work we've done with UiPath. This is our actual experience. Check the marketplace data that's out there," because there's a lot of information they can avail themselves of. That way, they can be satisfied that what our company is recommending is valid.
I may point out some of the key questions for them to look into. If they're trying to scale, what are the business problems they're trying to solve? If they're thinking about a Document Understanding requirement, they should compare what's going out there with other intelligent document processing capabilities and take it from there.
What other advice do I have?
As a partner, what has been helpful is that UiPath offers a not-for-resale (NFR) license. These are fully loaded licenses and ours is cloud-enabled. We're using them for PoCs very effectively. There is a lot of great value in them. I have a couple of projects now where we've asked clients to send us their sample data, their documents. We have our sandbox ready and I have one or two developers knock that process out with a turnaround of one or two days. We can bring it back to the client and say, "Here's your data and this is what we were able to do with it." That is very effective.
I really appreciate the way the product has been architected. It's a robust product set. We have built custom models with the UiPath toolset. We've had several use cases where we had to do so because there was no out-of-the-box solution, and the tools are great.
The AI functionality has enabled us to automate more processes overall. They are the more difficult projects to do because Document Understanding is not a pure, out-of-the-box solution. There is work involved in it but we've been successful at it. Once we get the models well-trained, the client starts to really see real value. They're seeing the straight-through processing that they're trying to achieve.
The client I mentioned earlier, the one with the 90 percent "throughput," is an example. That automation is the result of custom models. We worked hard on that and we were very successful. The client has been very happy.
Overall, the way I would rate UiPath depends on the support level I have to use. If it's Standard Support, it's a five or six out of 10. If I have Premium Support, it's a seven or eight.
Disclosure: My company has a business relationship with this vendor other than being a customer: Partner