We automate everything using the UiPath solution. We have some ongoing stuff, e.g., generating test cases and testing some of our development platforms. We need to define all the parts, such as how to test the entire environment to determine if everything is working okay.
We utilize all our services on the cloud, then they can be easily used across all our offices.
We only use unattended automation.
If a product is about to go live, we heavily rely on coverage from UiPath. This is during the development phase. However, when onboarding to production, we use other solutions, which don't rely on automation, for monitoring purposes.
When we are in the development phase, we have multiple edge cases, like iOS, Android, and other platforms, checking in. For a tester, it is difficult to check every edge case. Instead, we define automation test tools in UiPath, then our automated work does everything for us. Once it is done, it gives us a detailed analysis about where the product is performing well. We get handy videos before going live so we can improve everything and ensure that our end customer will not be impacted.
Our bandwidth has been drastically reduced, by nearly 60 hours, because of this solution. We have reduced the number of testers by three.
The most useful feature of UiPath is that it is very easy to use.
It helps us a lot with digital transformation.
The UiPath solution doesn't currently provide unique testing for mobile devices.
I have been using it for around six or seven months.
To the extent that we are using the solution, it is pretty scalable.
We use a third-party for support of this solution.
When we were facing some small issues going to the cloud, we tried to get help from the community. The community has been very helpful. Everyone has been willing to provide some good information to other users.
Previously, we were using an automated script to test everything. Now, with UiPath, we are automating everything.
We used the community to help us with the setup.
The vendor helped set this up and guided us how to do everything during the onboarding process. Therefore, we didn't have any issues with the setup.
UiPath has reduced human error by 20%.
We have reduced our costs by approximately $200 a month.
Creating our digital transformation didn't require any additional costs.
The vendor gave us a 30-day money-back guarantee. We were fine with that. We saw improvement during that time and kept the solution.
We didn't consider any other solutions.
I would rate UiPath as eight out of 10.
We primarily use the solution for our clients.
One interesting use case we've seen is that the product team leveraged UiPath to expose an API for their customers to then fulfill a service request.
It was part of their deal that, for them to sign this large contract with one of their clients, they needed this functionality. The product team has a huge backlog, and it wasn't going to make it based on everything else they had to deliver, so they actually leveraged UiPath to expose this and give them a service they just didn't have before.
When comparing it to, for example, Blue Prism, one of the key value points is, other than the full platform in general, the ability to trigger automation on demand. Basically, when the work gets loaded into the queue, the work can then be started without having to run things on a schedule.
The solution has improved the way an organization functions. For example, in general, in the context of RPAs, it's really about the focus of picking those tasks out of people's daily efforts so they can spend more time with the customers. What you get off the back of that is dollar for dollar savings. You invest in this tool, and you get back dollars by hours, however, beyond that, there are these peripheral benefits that you get that are a little harder to measure. You’ve got to have good guys out there to capture this.
In terms of endpoint satisfaction, customer satisfaction, you have to look at it within the business and their measurements before and after you've done something to actually see what is happening and attribute it to what you've done with UiPath.
We haven't done anything that hasn't saved money yet.
At the beginning of a journey, we were looking to get maybe 1X our money back in that first year. We try to get that at least. Depending on the size of the organization and complexity, it’s possible. As you go into year two, year three, you're almost looking at a multiplier reflecting that year. For example, a four-year-old program might get a company around 4X, if not more, in return. Of course, that also depends on how far you've implemented this product. You need to put money in to get money out, in a sense.
If you've got a pipeline of X and you only have three developers, you can only chew through that pipeline at a certain current rate. You want to look at the value and say, "Well, what if we doubled our staff?"
I have a calculator that shows, for example, if you have $10 million of savings sitting on the table through 20 things in the pipeline. If I put one developer on that, it will take me three years to go through that and build that out. At the end of that $10 million of value, imagine if instead, you had everything all automated on day one. That's a total max value, and you would get somewhere around 23% to 30% of that value returned.
If you double that or if you put a staff of three developers on that same pipeline, you finish earlier and you get about 75% of the total value. If you go to four developers or five, you get closer to 83%. Now, if you put 20 developers on there, you're only going to increment it to 95%, however, then you’ve just increased your total cost as you have to try managing 25 at the same time. The main idea being, based upon your pipeline and the size of your team, you can potentially increase your total return value within a fixed time.
The ease of the use of creating the building automation is actually improving year over year. For example, there are some training programs for UiPath, and it generally takes about a week to get through it. That’s on UiPath Academy.
If you actually use it with modern design, modern objects, and all the new things that have been released recently, you actually save time on training. If that shaves 20% of your training, you can also shave 20% off of your building capability or the requirements. BY using UiPath Academy, you save time on your projects.
It's fairly easy to learn, as a solution. However, it’s not that easy where you're just going to throw non-developers into it. Your first three days of UiPath training are actually doing .net. That's the one thing the market puts out there incorrectly is that your operations team can just jump on this. You still need a developer mentality as you're still dealing with exceptions and things that aren't the way humans think.
That said, in terms of usability, it's highly useful.
UiPath Academy helps streamline and keeps employees up to speed in the solution.
The biggest value of the Academy is that it's free. That's a major piece. It's fairly well organized, and they put things into channels based upon what your role is within your RPA program or your business, and that helps you stay focused in terms of what you need to learn.
The solution needs resource locking. This kind of leads toward scaling which is one challenge. It's not major. However, it is when you have multiple bots running the same process and they need to access the same piece of information to read and write. There's not a strong capability to manage the lock and have the capability to say "I have ownership of this file. No one else can touch it" and then release it, allowing the next one to pick it up. That's a key differentiator that I see between them and Blue Prism. That one feature is lacking.
The studio design is a little different. If you go from one tool to the next, you might be a little shocked at how things are organized. I don't see them changing that any time soon. However, the design could be improved upon.
I've used the solution for about four years.
The solution seems to be stable. I haven't had any issues yet.
The solution is very scalable. I haven't pushed it to 100 plus or anything like that. However, based upon scheduling and triggers and SLA management, it's much easier to scale.
We did work with other RPA solutions in the past. The differentiation comes from the triggers, and the attended automation. The platform now is a big part of this.
For example, Blue Prism is one of the tools that we work with as well. If you want new functions, new features, say, process mining, you have to go to Celonis or someone else, whereas UiPath is providing this platform with new capabilities almost daily.
It also depends on what kind of COE you want to build. Looking at Blue Prism, they have a nice UI as well. It's very business-focused. With UiPath, you need to have some developer capacity. There's .net in there, and some people just might not get that. However, at the end of the day, if they don't get that, should they be building processors? There's a bit of a challenge there.
The initial setup is not that complex. It's more about the client's setup. For example, the domain, entries, things like that, would add to the complexity you face.
If everything goes well, you can get things set up probably in a few weeks. I would say a month or so is needed for deployment and implementors should set expectations. For example, security depends on how much the organization is ready to take it on as well. If you don't get their buy-in right away, then you're just going to get delays.
Most of the companies see a good ROI from the solution.
The pricing and licensing get a little complex. There are so many different options that you can choose from, and practice adds to the time to figure these things out. Whereas, with, for example, Blue Prism. It's a pretty standard basic model. UiPath gets a little hectic at times.
The customers that use the on-premises version tend to use the latest version of the solution.
While those using the cloud version of the UiPath apps feature are in the UK, the US users are not using that functionality. Mainly most of our focus has always been on RPA and then expansion. From what I've seen, we've mainly been using UiPath. At least on the North American side, it's been relatively new. That's why they aren't using apps yet.
We don’t have any clients that are using the solution's AI functionality in their automation program yet. I’ve only played around with it myself.
From a road mapping perspective, I'd advise potential new users that your key is the business case. If there's no business case, then this solution doesn't make sense for you to get involved or do anything else. The first part is to really understand the business case. Just to substantiate getting it into the company. Once you have that, that's basically your low-hanging fruit.
That said, the key is not to hang everything on one process, not to sit there and bank it, as the concept is a program approach. Over time, it is going to sustain itself. Companies need to be ready to look at a process and think if it's a good idea first. And as you move through the steps, you're basically doing additional checks. As you learn about the process, you're also learning what it's like behind each process and what the value add is. At each stage, users need to ensure that it makes sense to continue.
I'd rate the solution at a nine out of ten. While there's always room for improvement, market-wise they are at the top of their game.
UiPath helps us to develop and build a center of excellence for our clients. I do development and technical implementation of the bots, best practices, and teach others how to do the development.
The client that I'm working with now is in the financial services sector. They do banking and life insurance. They do a lot of contracts and billing, backend, data entry-type work. We process all of the return mail that comes in, scan it using Doc Understanding, publish new bills, generate form letters, and all of those tasks that go along with managing the client for life insurance, annuities, 401K, etc.
A lot of the benefits we've seen are from FTE hours saved. We are looking at almost all of our processes, and it saves us at least a thousand or more hours per year before we go into implementation. We have around 20 in production. We're saving between 15,000 and 20,000 hours of process time.
From the user's perspective, people are happy that they don't have to do certain tasks that they didn't like to do. I only have one of those bots where I have a group of people that prefer the way they've always been doing tasks, but that's more of an organizational thing. I'm seeing across the enterprise with other folks that they're very happy to have this. They are putting more use cases in, and the frontline workers are bringing in use cases. Of course, we need to vet a lot of those so that we get enough bang for the buck, but we're finding a lot of adoption across, up, and down the whole scale so far.
There's also been a reduction in human error. There are so many use cases that have been more on the production side of things, like productivity as opposed to risk avoidance. We enter data and we do bank transfers, so it's important to key the data correctly. We use the attended bot to do that. We took a paper form. We push it in, it comes in as an unattended bot in the backend to read an email from a person and put a transfer in place. It gets approved and put in the queue.
When they run the attended bot, it allows them to do an RSA key into their external site, take the data, watch it go in, they see it, we audit it on the backend with a second user, it gets pushed in, saved, and submitted. From that perspective, if you're dealing with 10, 50, or 100 transfers a day, where you could key in the wrong number, it's important.
That's been helping. Employees are happy that they don't have to type it all in, and that they don't have to worry about the errors as well. It offers peace of mind for those folks.
Getting the bots going and working is the most valuable aspect. We have about 20 or so in production. We're building out from there. We've been very focused on Studio and Orchestrator, as opposed to some of the other product lines. Because a lot of what we're dealing with pertains to advanced technical people like myself that are helping them along that journey.
It's easy for me to build automations but I am a computer scientist. I have a deep technical background. A lot of what I've been doing is trying to teach people how to build resilient bots, and how to build processes that will run. To me, one of the big things to meet your ROI is that you need to build things upfront that work. You need to verify them, test them, componentize them, and put them together. Otherwise, you're going to spend too much money on the backend with maintenance.
If you can get people to think about what do to in the event of a failure, even from the developer side of it, then they can create things that we can run, and we don't have to do so many new maintenance and operations tasks on it. That's vitally important.
I have used the UiPath Academy courses. I'm a certified developer. I didn't know UiPath at all. I went through the Academy and trained myself. When I brought in new developers, I had them do modules and I sometimes go visit them.
The Academy is pretty good. It's very helpful to have something like that. Personally, my favorite side of things that UiPath is bringing to the table, is a community edition in the cloud. I can go out and play with the latest and greatest. I have my client's laptop, but I also have my own personal laptop and I go out to the cloud and do tasks out there.
I want to bring what's new, help bring to the forefront what we might want to do in the future, and get a hands-on perspective, without having to go to the client and bug them about bringing in a license for something. That's great and I hope they continue with that.
The fact that they're not charging for training is great. It brings on more developers. The barriers to entry for people are low. And the more developers you have, the more adoption you're going to get.
There's a lot of technological growth that should be done. They need to learn from customers. I talk to people about Doc Understanding which is relatively new. There's a lot of people in the document world that have more experience. They should learn a little bit more about what Kofax has done over the years with their validation actions and those types of things.
There should be more growth, but the platform is there. As they grow those things they should take each piece and make it better. If you start with a good platform and you build it up, it's going to get better. What we have today is very usable, and is only going to get better. I look forward to it.
They should talk to their customers and understand their use cases. Give customers what they need.
I have been using UiPath for two and a half years.
Stability has been quite good. I see technical glitches once in a while in the Studio, but when you're running on Windows, it happens. The glitches don't happen very often.
It seems very scalable, in terms of rolling out new processes. We're more limited by machines and getting things set up than we are by what Orchestrator can handle. We have one attended bot and we're 95% unattended.
We have plans to increase usage. Our clients are growing from two developers, a QA and a VA, to a VA, and a team of two pods of six or seven developer QA types, to implement use cases over the next couple of years. They're on a very high trajectory of growth.
I go out to the community a bit. I Google looking for what everybody else has said and figure it out. We only have a couple of different use cases where we've gone back to UiPath, and the ones that we had the most difficulty with, we went right through the local sales rep to get things going. I found their support to be good.
The initial setup was straightforward and easy.
I set up Orchestrator servers, I put bots out into the systems, and I installed Studio in the client's environment. The only problem I have is with the way the client environment exists. Security gets to be a hassle.
One of the things the company focuses on a lot is employee satisfaction. From a cost perspective, we haven't necessarily gotten to that level. I've been there for two years. I'm a consultant. We have other consultants. We're saving $15,000 a year, while we're displacing certain cost dollars from the people that did those jobs, we get paid more.
Cost-wise we're fairly evening out, and probably bringing an MROI. This is a longer scale process for them, to take them along this journey. It's important for businesses that go under that, to not necessarily focus on year one, year two. We look at this as a longer-term endeavor for them. The key benefit that they see out of it right now is the future. The workers are satisfied not having to do the "bad" work.
I found UiPath to be pretty cost-effective.
I would rate UiPath a seven out of ten. I see it as a maturing product. It's done very well, because it is stable, and it does build real use cases. But I look forward to the future. There's a lot of good going on here.
We're a revenue cycle management company for medical billing. We've reallocated our charge entry employees. We're using bots now to do the charge entry on medical claims and then also payment posting along with eligibility and AR. We've been able to reallocate about, just within this last year, probably eight employees. They've been reassigned to more valuable work - things that the bot can't do and actually requires a human to do. We've been understaffed, so it's actually worked out great for our company.
The ease of building automation isn't a problem. It seems to be very easy to do to a point. Our challenge is we work in a live environment. We're not able to use a test environment when we build things out. We have to go very slowly.
I'm not that familiar with the product, with the solution, however, the UiPath apps feature and OCR are great. That said, we're not using any of the apps currently.
The biggest benefit we've seen is the accuracy. Even just with employees calling in sick or not having enough staff. We’ve been able to fill those roles.
The robotics piece has been a huge thing. We're doing medical claims. We're always worried about claims not getting paid. This has been able to capture those claims so that people get paid the first time. One of the other things we track is how many times we touch a claim. For example, how many clicks. We couldn't do that before. That's been very valuable to us.
We’ve improved our efficiency in a way for sure. Even just our cost analysis has improved. When we do new contracts, we know what it's going to cost exactly.
I don't know if it's UiPath as much as just what we do is really complicated. Even the consultants that we've used with UiPath, even they've said, wow, this is very difficult what you guys do. There are a lot of moving parts, so it's not as much of a UiPath problem in terms of limitations. It's just our own processes.
Right now, I don't think I've been on there long enough to know if there are missing features or functionalities I’d like to be added.
I’m talking to people right now, to see how it can do things better or how we could use it more effectively. We’d like to discover what worked for other people.
We've been using UiPath for about maybe a year and a half tops.
I haven't had any problems or concerns right now concerning stability. The biggest concern I do have is that we've already invested six people in this. We're going to have a lot more that will, more or less, not have the robotic piece as part of their job. That work will be reallocated. I have about a hundred employees that UiPath could technically reallocate.
When I look at that, I worry about if something does happen or it doesn't work or there's no backup. Then, suddenly, I don't have employees. Right now, we can jump in and some humans can do the work if necessary. My concern is that in the future they won't exist. This hasn't happened yet. I hope it doesn't.
Scalability hasn't been a problem at all. We can just continue to add bots every time we need them. It's been easy.
We started with two. Three months later, we added another two. After another three months, we add another two. From our standpoint, it's great. My UiPath rep was shocked that I keep adding more, so that's good.
I have not used technical support.
That said, we had one issue with UiPath where something didn't work. We talked to them and it was taken care of within a couple of days.
My vendor is working with them. They mentioned there was an issue with insights that they are working through. Insights are still not quite functional, or there are some resources we need. However, the vendor is dealing with it directly. It's a work in progress.
We did not previously use a different RPA solution.
The initial setup was pretty easy. We didn't have any challenges with that. I contacted one of our vendors and they ran with it. We didn't have issues at all.
With the vendor, it took us about 30 days to deploy UiPath. After that, in terms of implementing bots, the first bot took us about three months. Once we did the first one, it just went really quick after that. We could reuse some processes which made it faster. There was a lot of reusing of the same. We were also internally understanding what information they need and how it works.
It was all new to us. I'm still learning the acronyms they use. We need to learn what they are talking about. We’re not IT-based at all. It's definitely different.
We had the solution implemented by a vendor. They implemented it all. We didn't have any challenges as far as that goes.
Our experience with the integrator was good. I would say that they didn't realize how challenging it was going to be or, at least, the person who integrated didn’t. At the same time, they know almost everything about my business now.
UiPath has saved costs for our organization. For example, we’ve allocated six employees that are paid around $40,000 a year and we've implemented six bots to do those same functions and they're around $8,000 a year. In a way, we’ve doubled our staff, and almost tripled our ROI.
We had a problem before with the pricing, however, for the most part, it's fine where it is now. My ROI is fine. It works great. I have zero complaints.
You have to do a package at a time. That's my only challenge, where sometimes I don't need that many licenses.
When you first sign up, it's a package that can renew every five years. I don't necessarily need everything. I'd prefer just to pay for certain pieces.
We did not evaluate any other options. We started using UiPath due to a referral at a neurological healthcare conference about four years ago. The speaker suggested UiPath. I actually didn't know of any other company until after we were on UiPath. We've since talked to others who have used other solutions and they mentioned that we made the right choice when we chose UiPath.
We started on-premise for the first six months and then we actually moved to the cloud.
We do not use their UiPath apps feature as of right now.
We are mostly using unattended automation.
We haven't really calculated the reduction in human error. We're just moving on to our Insights app. We're just getting ready to launch that, so we're not there yet. We don't know what that turnaround will be.
We do not use UiPath's AI functionality in our automation program right now.
Our teams have not yet used the UiPath Academy courses.
I'm a little concerned about having to bring on more people that are not in this industry. We're going to have to start them over from the ground up, which takes time.
When we first started, we wanted to know if it really worked. We got a certain budget and just started using it, and now I can say that yes, it does work. We can see that now that we've stepped back. We should have done it earlier. That's what I would tell people. I would definitely tell people to look at it first, before anything else.
I'd rate the solution at an eight out of ten.
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.
We primarily use it to reduce manual effort and to increase accuracy and on-time implementation. We perform end-to-end automation, since we are a company where SAP is used very widely. We use UiPath for SAP automation.
We develop both attended and unattended solutions. We're using the platform as a service and it's hosted on-premises.
So far, we have 15 bots in production. As a result, we are saving a lot of time, although I don't have a figure right now, as well as a lot of effort. We are also able to provide timely delivery to our customers, so the automations have been generating a lot of buzz here.
Attended automation has helped to scale RPA in our organization by automating processes that require human-robot collaboration. An example is our invoices that have data that needs to be scanned. The scans we were receiving did not have the accuracy that we were looking for. We also had a hard time getting the results through OCR. With the help of attended automation, we are able to have users verify data when the bot is running. Once the verification is done, the bot will perform the rest of the actions.
UiPath also definitely helps us with process analysis.
Although I have not used it yet, they have recently introduced a feature which brings more accuracy to the selectors, using the image and the selectors themselves. I feel that will be good. When we are creating selectors, there are elements that it's hard to get at, or there are times when the selectors get changed for some reason. The new feature should make it easier to work with in these situations.
They have also recently added a feature for attended automation, Picture in Picture, which is also nice to have. It's helpful because you don't want to just sit back and let the bot run and not work during that attended automation. Using the PiP feature, you can have it running on your desktop without having to interrupt it to your work.
I would also compliment them on the UiPath Academy, the learning platform that they have built. It contains everything that a developer or architect or tester or, anyone who is looking to benefit from an RPA, would need. It's all there on their platform. It helps speed up onboarding employees to UiPath. When I joined this company, I had prior experience with the RPA and UiPath. But two of my colleagues, who were working on test automation, didn't have that kind of experience. The Academy helped them to get started. We aligned quickly, once their fundamental developer training was done through the Academy. The Academy helped them align with the current practices of UiPath and RPA.
One area that needs improvement is monitoring. I know there are tools that let us see what a bot is actually doing on the virtual machines. If we could get that kind of offering from UiPath that would be great, because when a bot is running on the machine, we don't know what it's doing. Although we have programmed it, there are times when something causes a bot to fail. During such instances, the bot behaves differently when we run it in attended mode than it does in unattended mode. It would be great to have a feature where we could see, on a screen, what the bot is currently doing.
We started this UiPath journey two years back.
I act as a UiPath lead because I joined early and I have some prior experience with it. There are three other people in India, and one more in the U.S, who use it in our company. The one in the U.S. does the managerial stuff and it's the developers who are in India. Then we have the business users for each of the bots and they also use UiPath. And we have a set of about 20 users who use the attended solution that we have provided to them.
Robots on the SAP system seem stable, but on the web they sometimes lack stability. Still, it's not a very common occurrence and I have overcome any issues with the help of the Trilogic. For example, we had an issue while getting an email from Outlook. A UiPath robot is not able to do that. It will time out. With the help of the Trilogic, we were able to overcome that.
Initially you have to put some effort in to obtain stability and then it is mostly stable. Some maintenance is required, but that's most probably when requirements change, or to add to the stability, but it's not a lot overhead right now for us.
It's highly scalable, in both development terms as well as business terms. We have the capability to add on robots. We can add to the VDI or machine anytime we want. They have put some serious thought into the scalability, when it comes to giving support to developers as well as the business.
We plan to increase our usage of UiPath. We have a lot of things in the pipeline. We have almost finalized on providing RPA as a service, something that we will offer internally. Right now, we are giving this free of cost to our customers who are the business people. We did so to get some attention and to create some interest in the tool. Now that we have almost finalized this as a service, we are going to involve business analysts who will be helping us to find more RPA use cases and finalize more RPA solutions. That means our usage will increase. We're still in an early phase.
I haven't had the chance to interact much with the technical support because the forum has so much information. If I browse through the forum, I will most probably get an answer. So I haven't needed to go to the technical support for any answers.
We have both test automation and UiPath working in parallel. Test automation has been here for the long-term, something like 10 or 15 years. The two guys who work with me, who didn't have prior UIPath experience, are working on that. That part mostly requires maintenance, and they now mostly work on UiPath development. So although we had a test automation solution, we didn't have a business automation solution. That is why we went with UiPath. It gives us an edge in business automation.
The initial setup of UiPath was pretty straightforward. I didn't find anything unusual or complex.
We went through an upgrade recently. We have dedicated cloud architects who helped us do it. We got instructions how to do it from UiPath support and we conveyed those instructions to our cloud architects and they performed it at their end to get UiPath cloud upgraded. Upgrading didn't take much time. It was done within half an hour.
One more feature that is useful is that earlier, we didn't have the option for a concurrent-user license. With the help of the concurrent-user license, we can save on licensing costs while running multiple bots under the same license.
If you are going to implement UiPath, my advice would be to look at how you are going to gather the requirements and how you're going to manage the requests for UiPath.
Also, get some low-hanging fruit first, before going into the complex automations. That way, if you are new, the low-hanging fruits will generate confidence in the solution. Once that kind of confidence is generated, you can move ahead with the complex automations and complex solutions.
Go through the UiPath Academy extensively. They provide good training materials that I don't believe are available elsewhere. So I really recommend that. I recently attended a dev conference and I learned a lot about this stuff. I work in a closed environment where I don't have much of an idea of what's going on in RPA. This conference helped me keep in touch with the current trends in RPA and UiPath.
I rate UiPath at eight out of 10. For me, that's a very good mark. The two missing points are because there is scope for improvement. Overall, I'm pretty happy with UiPath.
We are using attended and unattended robots, Orchestrator, and Studio.
We are in the financial services industry. A lot of what we do is background data processing, and we use the unattended robots for a lot of it. We do have some attended robots as well, but most of our processes are unattended.
I am a developer, so I primarily use Studio. I write the instructions for our Orchestrator Application Manager to do everything we need in Orchestrator.
We are currently operating an on-premises deployment, but we're in the pilot group for Cloud, so as soon as we get a date on that we'll probably be migrating.
One of the primary processes that we've automated is reporting. Prior to automation, our users were only able to run a few of the reports, a few times a week. Now, we're running every single report that there is to run, which is probably four or five times what they were able to do, every single day. Every morning they receive a summary of that work, so they're able to just get on and look at it, rather than during the close of the day. In financial services, the close of the day is crunch time. We work really hard to make sure that everything is done within a set about of time because there is a domino effect. One person has to be done before the next person can finish, and they're not having to dig back and try to figure out when these issues happened. We're providing it to them upfront. We can say exactly what happened, which account they need to look at, and on what date. This means that we're ahead of the issues, rather than trying to backtrack and find them.
We are not currently running in a Citrix environment, but the only reason we're not is that our sister company hosts our Citrix environment, so we can't install any of the services that make those environments much easier to utilize. For example, we can't install the computer vision component because we don't own it, so they won't let us.
Our team is really small, there's only six of us on the actual RPA team. However, we work really hard with the business to get buy-in in every department. We're trying to roll out at least one automation in every single department. Our company's goals for the next year, I believe, every associate of the company is supposed to have proposed a task that they are doing, whether it's daily, monthly, yearly, whatever, that could be automated. Then our team will ingest that, prioritize that, and work through it. But, we're really trying really hard to get our whole company involved, and we're getting ready to kick off this campaign to try and get more attention to it and to try and get people using it. We want it to be more than just a buzzword. We want it to be something that everybody's talking about regularly, and using, and excited about.
When it comes to getting people interested, I think it's probably a combination of education and sharing the experience of those projects that we have rolled out. When people are really seeing that with the projects that we've rolled out, our close is shortening, they become interested. What we say is happening, or will happen when we're rolling these automations out, is happening. Getting that to be shared from process owner to their team, to the teams that they're working with, it acts like word of mouth for those that are affected. We don't like it to just all come from us, the technical team. We don't want to simply tell them that it's going to do something. We want others to talk about what it has done for them and suggest they should take advantage of that too.
With respect to how easy it is to automate our company's processes, on a scale of one to five, I would rate it a five. We don't struggle with it.
I took the UiPath academy training, and I love it. We are looking at an unrelated tool right now, and we found no comparison between their training and the UiPath Academy. We were spoiled with UiPath Academy, and we didn't really realize how good that training really is.
The thing that I love about the developer training; the level one, level two, level three... level one really does walk you through it. It gives you, literally the walkthrough, so when you don't understand, you can go back, you can look at, and see exactly how to do it. But by the time you're in level three, it's not doing that anymore. The requirements are a little bit looser, you have to figure out how to interpret the words or the requirements, and it becomes more challenging, but I think that that's important, because, by the time that you're actually working real projects, it's not a walkthrough anymore. You have to figure it out on your own.
From the point that we purchased our UiPath license until we had our first robot was approximately three months. It did take us a little while, but we knew that we purchased our licenses before we were really ready to hit the ground running. We function out of such a small team, and we were still working with UiPath trying to figure out which partner we wanted to bring in for consultants because we wanted somebody with experience. We didn't want someone who just finished the training just run in and try, and I think we learned a lot working with that consultant.
We did work with a second consulting group, Machina Automation, and we loved working with them. They're great. They're just so supportive, and they really want to make sure things are right. It's never just sending them the requirements and pounding it out to get it into production. We work with them really deeply to try and make sure that they understand the process, we understand the requirements, they express their concerns to us, we express our concerns to them, and we work together. It's not like we just send them the documents and they send it back as a project. The whole way through we touch base with them every single morning. They're always asking what more they can do and how they can help. They ask if we're happy with what we received.
We do time card reviews, so the time that they spend with us we're actually able to go back and validate, based on that, what they've said they did, that indeed it is what they did. We had received some scrum and sprint training from them. We've had actual developer consultants, we've had mentoring hours for our developers. So we've had a lot from them, and they've been able to help us with everything. Anything we ask, they try to accommodate us. For example, we asked if they had any experience with Kibana. They did not but said that they would find somebody who does.
With respect to saving time, I don't actually track that because I am a developer, but I know that our goal for next year is twenty thousand hours. That's the big goal that we're working towards. With one of our processes, I think we're going to hit about thirteen thousand hours if we can just get that one process done. That's a statement review. We sent out tens of thousands of statements, so we'll be able to review every single one of those. This would be a huge saving in time.
I think right now we have about one hundred and thirty-six processes in production, and a lot of what we've done so far is in the finance section of the business. As such, a lot of those are only run on a quarterly, or monthly basis. We have some annual processes, and we have very few daily processes, but those daily processes add up over time.
In addition to the hours that we have saved, one of the big things we're working on is accuracy, control, and staff avoidance. Staff avoidance is the work that couldn't have been done otherwise because we would have had to hire someone to take on all of the work. So, we're able to do more than what our current staff is capable of doing. We add that into our time savings.
But, more than that, we really do focus on accuracy and timeliness. We're able to speed things up. We're able to ensure that things are exactly as expected. We spent a lot of time in the early stages of our planning, really trying to optimize our processes, so we get our original documentation, we take it, and our team works with the business to optimize that. After we get sign-off and we've optimized the manual process and got it documented and signed off, then we do a developer review and discuss ways that it can be made easier. Then we do a review for development and optimize it. Finally, once we get that signed off, we actually start our development.
We spend a lot of time on the front end of the process, making sure that everything is accurate and reliable, and we're going to be able to deliver faster as expected, and it's going to be able to handle all of these different errors or use cases. Following this process has worked well for us, so far.
I think the most valuable feature is being able to run processes in an unattended way where we can schedule them, and then have the report sent to the process owner's inbox in the morning. The is great for us, and we use it a lot. It saves the users a lot of time, and we're able to do a lot more for a user than they were ever able to do on their own.
I would like to see a biweekly scheduling option in Orchestrator. We've actually built into our automations a roundabout way to process every two weeks but it would be really nice to front end a biweekly schedule. Being in the financial services industry, we do have a lot of projects that run on weird schedules. We've kept some of our automations attended just because they're ad-hoc. They might need to re-run them. We don't want to have to wait for Orchestrator managers to kick those processes off. But, outside of that, there is no need for this one to be an attended robot. It's a perfect candidate for unattended automation, just the scheduling is the problem.
With respect to the stability, on a scale of one to five, I would rate this solution a five. We haven't ever had any issues with it.
We did not use another RPA system prior to this one.
When I first started at the company as an intern for my department, it was only myself and my boss, who's now our COE manager. The very first thing that we did was meet with all of the different functional departments of the company, and we explained to them what RPA is. We explained the types of processes that it can help take off your desk and asked for ideas from each department about what could be done to help them.
We took that, and we built this huge backlog of perhaps three hundred different items, prioritized them, and worked with others to explain that it was needed. At this point, we did PoCs with UiPath and Automation Anywhere.
I found the initial setup to be straightforward. They had me sit in on it and I don't work infrastructure, so there were some things that kind of went over my head. They did a lot of planning. After some help from UiPath, it went really fast.
UiPath helped us with the implementation. We worked with them to really figure out what our infrastructure needed to look like.
We evaluated both Automation Anywhere and Blue Prism in addition to this solution. We ruled out Blue Prism pretty quickly. Our sister company uses Automation Anywhere, but we liked UiPath, primarily for the reason of our experience working with them and the sales team. To me, it was so much more than just working with the sales team, they're our friends now. We still talk to them and we have relationships with these people. We actually just ran into one of our developers for our PoC. It's a culture you want to be a part of.
In comparing with Automation Anywhere, one of the big reasons we went with UiPath was the support that we received. Any question we had was immediately answered. If they didn't know the answer, then they would search to find the right people in the company who did. I think that that's more valuable than just saying that they'll find us an answer. You always got the feeling that they were going to follow through, just by the conversations that we have had with them. I think that really sold us, a lot.
Also, watching the road maps for both companies at the time, initially it seemed like Automation Anywhere was ahead, and that UiPath was catching up. Then, when UiPath started releasing what they were going to be doing, as opposed to only what they were working on right now, we realized they were really going to be moving ahead. I think that kind of sold us too. Just watching what's on the road map, and how it fits in with what we see our company doing in the next few years, they aligned really well. I think that was the point where my boss really realized that it's going to be a good fit for us.
When I was in business school, they taught us that the things that users like the most are the things they didn't know they needed. I think UiPath does a great job of anticipating the users' needs, and they meet them before we knew that it was what we needed. I am excited about the next release.
I recently had a discussion with my father, who works for one of the energy companies in my state. He works at the IT level but on the infrastructure side. When I explained to him our savings in terms of hours that we have had since adopting RPA, he was very excited and is now heading their RPA initiative.
RPA is making a difference and it's really changing the way the workforce works.
My biggest advice for anybody considering this solution is to get their quality improvement, and Six Sigma teams involved because I think it makes a huge difference in terms of understanding processes. When you can get your processes understood, you can get people on board early, at every level.
I think it's really important to have proponents for automation, just in general. You want to have the automation mindset at every single level. Of course, it's important to have your C-level bought in, but it's important to have the people who are doing the work bought in too. If you don't get their buy-in, it's going to be much more difficult because a lot of the work that you're automating is at their levels. You're working with them on a day to day basis to understand their process, to understand all of the rules behind what they're doing. So, buy-in, and process understanding, that's just critical. You can't move fast without those two things.
We have nothing bad to say about UiPath. We have regular communication with them and all of the concerns we have are always addressed. They're addressed quickly and they're addressed well. They really listen to what the customers want.
I would rate this solution a ten out of ten.
The primary use case is invoicing and billing. The first thing that we used it for was some content migration from one video hosting provider to another. We later on moved to invoicing and billing, which included time sheets, management, and feeding data into our accounting system.
The features that we use the most for our use case include reading PDFs, email integration, and web and desktop automation talking to other desktop software.
We have generally found it easy to use, but we also develop some extensions. We are actually a software development shop, so we have developed extensions to the core UiPath platform. They have made it pretty easy to do that.
UiPath could use more OCR use cases to help with those features.
I would like to see higher end AI type features natively in UiPath. Some native integration over time would help.
We found it to be quite stable.
We have a relatively small use case. Most people have entered the market on a small scale. The maturity will come in, maybe over this year, as people start to scale up.
I expect some issues will surface when it starts scaling up. However, that happens with any software.
The eagerness of UiPath engineers and their salespeople to help us along the process has helped us align ourselves more with UiPath.
Support is good, helpful, and eager to help.
The UiPath Academy is great. It was one of the reasons which made us choose the tool, and align ourselves with it. It was easy to get the software, and train on it. If you're doing professional work, you don't want to have untrained people work on it. This will not lead to success.
As a software development shop, we value training quite a lot. They made it easy to help our developers come up to speed with the software and get certified.
The initial setup is quite easy. We have worked with some other RPA tools, but they took us quite awhile to get setup. With UiPath, it was relatively easier to get started.
We have seen ROI by it saving some hours for us. We are a small company. We use the tool mostly because we want to learn about the software. We also save some hours, but we do it to learn and help other customers who are doing it at much higher volumes. The savings for us is relatively lesser than the savings for a larger customer.
ROI is a bit tricky. Customers need to implement simpler use cases: Get ROI from the tool, learn it, and re-implement it. This is just the nature of how RPA works. I see a lot of opportunities for it.
When customers start scaling up their use of RPA and have learnt how to use it, that is when the real ROI will start trickling in. When you start off, it will take some effort to get it right. Once you developed some maturity with the process, and you're scaling up a lot of use cases, and you have one bot doing a lot of different things and being able to share a lot of processes with a few bots, that's when you will start seeing good ROI.
This tool gives opportunities for people to be productive in other areas, which is hard to measure sometimes. The first step is to get them there, then determine where you can go from there. ROI is a very long term thing. The product lets people focus their skills on what they are good at, which is a type of ROI.
UiPath made it easy to learn their software. When we looked at a variety of RPA tools initially, UiPath was the easiest to get started with. It has good Academy content and an open platform, which is easy to download and start using (the Community Edition).
We have been looking at other RPA solutions, but we like UiPath quite a lot.
