I work at a financial firm where we do trade settlement activity. We are using UiPath for cleaning up data, doing reconciliation, and finding where the trade breaks and trade files are. It helps us lay the groundwork for the value add work, which comes later.
It allows us to grow our business. The use case that we have is a huge time saver because we do not have a lot of volume right now. We are looking to sell part of the business and get more clients onto it. The only way we could do that or even open that door for possibility is to automate and go through a lot more volume.
Our teams are under huge pressure because trade volume has gone up over the past year. UiPath is just getting us back to the status quo and then also opening the pipeline for more volume to go through. We have a very strong program that encourages people to get trained up on tools.
StudioX is going to be a big game changer for us. We found with the other tools that we use that as soon as we put UiPath in the hands of everyday users and ops users, they will be able to quickly learn it. This will make a big impact because we will get big volumes and projects coming through.
UiPath has done a good job coming up with the broadest use cases. However, I would like to see them dive into more industry-specific use cases. For example, checked OCR and brokerage statements are common. Anything unique to the financial industry would be useful for us.
We have using UiPath since February when it got brought into our team. We just had our first box go live about two weeks ago. We have had three go live so far; one using StudioX and two using Studio.
So far, I haven't heard any issues. We are always going to expect issues, but so far so good and I hope the stability is good. Alteryx had issues at times, which created some pretty big problems. Hopefully, UiPath will not do that as much, because we are expecting to lean on it.
I have not used them directly.
It was not so much a switch for us. We are still using Alteryx. UiPath is a much better automation tool than what we were using before because it was self-service. We didn't have to have our COE build it and related solutions for us. We have similar functionality with Alteryx. Anyone can learn it and start building and go through our governance process. Doing so, they can have a huge impact on their team.
We are a large company and the initial setup took our COE quite a few months. However, I believe their experience was positive overall. A lot of the issues we had were internal and concerned how we were going to do our governance. We were very strict about that.
Getting people access was easy and so was learning to build. Everything on the UiPath side went smoothly.
We're a mature automation team. Over the past four years, we've delivered well over 150 FTE. We're always looking for new tools and to pick up some of that automation that we couldn't do before.
UiPath has helped with data scraping and plugging into websites and combining that with Alteryx. We can attack 90% of our use cases now. We can not deal with the other 10% for internal governance reasons and not so much capability.
The three use cases we have implemented with UiPath have saved about half an FTE.
I know that the reason we went with UiPath is because it is a lot cheaper than the other vendor we were using. It is of a better quality as well, but it is less expensive to run on an ongoing basis.
I'm not sure if we evaluated other options. My team does not look into the suite of options. We have a separate COE that sets everything up for us. We are tasked with implementation.
My advice is to first build a good team that you can trust. Because great tools are useless if you don't have any builders or people that know how to use the tools. That is what we have been focused on. Also, have very specific support for your team.
In terms of product testing, I use it in the product with the test suite to mount the test manager and then follow with the requirements. After that, I create the test cases and I'm running them on different platforms on the web so that I can proof back from the web with test suites.
I use the different tools of UiPath. However, in the future, I’m hopeful UiPath will help us to expand into different countries. right now, I use it personally. Soon, the entire company will be using it as well.
The automation of the cloud offering helps to decrease the solution's total cost of ownership.
The document understanding is great. I interact with different documents of people. The IDs of one are different from a document or a PDF. For example, our contracts, et cetera. It can understand the differences.
I’m not quite sure about the ease of building automation using the solution just yet. It seems to be moderate. Not too easy or difficult.
The solution has helped our organization save costs. It’s likely saved us about $10 million.
UiPath has helped us reduce human error. That’s had a partial impact on our business. Our techs understand the different types of processes and competencies it can help with. Regular users cannot see this just yet.
It has freed up employee time. It’s allowed for a focus on higher-value work. Employees seem happier. It’s an easy tool to use and deploy.
We’ve used the UiPath Academy courses. All employees take the course and learn about it. You still need more education afterward, however, the biggest value of the Academy is the knowledge. I've got people who are new in the company and I can just say "take these courses." It's accepted by everyone as part of the process.
The graphics could always be improved.
I've been using the solution for three years.
The stability of the solution is good. UiPath has a different release each year at the moment.
The scalability is great. You have a manual so you don't have to do the courses. You can read through it.
We have about 200 users at this time. We have different areas in the company that uses UiPath. For example, the administration uses that tool. You have a test suite and you can have development using the UiPath Studio as well.
Technical support has been great. Whatever my query is, they are able to answer it.
We did not use another RPA solution before UiPath.
The initial setup was straightforward and simple.
The deployment took about one month.
The pricing and licensing have been great.
We did look at different automation tools before choosing UiPath. We looked at Blue Prism and Automation Anywhere, however, we ultimately chose UiPath.
The UiPath Academy courses were a big selling point. Also, its ease of use. Automation Anywhere and Blue Prism were so difficult to understand. UiPath is more interactive and it's more visual.
We're a UiPath partner.
I've used both cloud and on-premise deployment. Right now, I am using the cloud.
At this point, we do not use UiPath's apps feature.
We have not used the solution's AI functionality in our automation program yet.
If I were to advise anyone on using UiPath, I'd let them know it's easy to use. You have manuals and courses to help you navigate the solution. The new releases make it so that it continuously gets easier.
I would rate the solution at a ten out of ten.
We're still building up the program, but right now our primary use case is for report review. We're looking to branch that out more.
It's reviewing reports. I worked for a bank and there are reports of transactions from the previous day. UiPath was looking for anomalies for fraud and things like that.
It's still very early on but we have caught a few instances of fraud that we would not have if we weren't using UiPath.
UiPath has reduced human error. We're very early, so it's not a big impact, but we did find a few instances of fraud that we would not have found without it.
We see time savings for our users in the sense that they now can do more tasks that should have been done all along but weren't getting done. That's more where the gains have been this far.
I like the whole ecosystem. They're not just looking at the automation tool, they're looking at automation from end to end.
It's pretty easy to build automations. I have a coding background so it's not particularly challenging for me to use Studio, but for a person who does not have that coding background, I think that the Visual Builder guides you through the process pretty easy.
UiPath Academy is a good training program for people without that coding background. It's good to get them into the mindset of how exactly flows works of automation.
The Academy offers us familiarization with Studio and how it functions.
The API integrations need improvement. They should build a better framework for the ability to integrate with other external APIs.
I have been using UiPath for less than a year.
I would rate the stability an eight out of ten.
It's pretty straightforward. It either runs or it doesn't. Occasionally it does crash and we've had to restart services and whatnot to get it going again.
We haven't been using it enough to see how it can scale.
There are two ITs who use it in my company.
We have plans to increase usage.
We don't really see our staff as being good candidates for citizen development. There are a few that could, but we do plan to expand out into other departments as far as gathering ideas and implementing processes for other departments.
Their support is pretty average. It's not good or bad. It's off-shored. There are always difficulties with cultural differences and language barriers. They know what they're doing but sometimes it takes a while going around in circles to get the question that you're asking across. That's pretty normal. Most companies are the same way. I would say all companies have huge room for improvement there.
The initial setup was pretty straightforward. It was easy. The installation instructions walk you through the process. We didn't run into any problems. It took less than a week.
We also looked at AntWorks and Blue Prism. We went with UiPath because of the maturity of the product that seemed far more mature than its competitors. The product seemed more thought out.
Based on our experiences, I would say you have to have employees that are dedicated to doing this. This can't be done as a side project.
I would rate UiPath a nine out of ten. Nothing is completely perfect. The stability of it could use a little bit of improvement. The support is not great. UiPath is very good, but no one is perfect.
We've got mostly finance use cases including a lot of accounts receivable and stuff like that. Then, there is a lot of work where I do trading settlements, so a lot of settlements as well. The back office automation's there, too. We're still getting used to it and still getting started.
We've been able to expand up to citizen developers, and have been able to show them how to do various things. It's easy to pick up, so a lot of citizen developers are learning it now, and with little to no coding experience. It's been great.
The recorder has been great. Just being able to really start your automation there, and just modifying them a little bit and then getting them really in production has been helpful.
The solution has saved costs for the organization. For example, I used to do back-office stuff, and I was able to move to more of an IT role. That was definitely a savings there, and obviously, no one had to automate it after me or do it manually after me.
We have found that the solution has reduced human error as now it's a bot doing it. It's really reduced errors due to the fact that no one has to check each time to ensure the work is error-free, and, in general, there are a lot fewer errors.
The solution has freed up employee time. For example, as I mentioned, I myself have moved off of back-office tasks and, in doing so, the company did not have to hire someone after me. We've likely saved 10,000 hours in a year. We're really happy with that result. The additional time has enabled employees to focus on higher-value work. People can now just quickly audit it and then move on to something more important.
The Academy is great to use. We've been able to learn a lot from there. That's what our citizen developers will look at as they get more familiar with the product, and as we show them how to develop items. It has positively affected the process of getting employees up to speed on the solution. A lot of them have little to no coding experience and the Academy has helped by showing them what they need to learn. The biggest value is if they have little to no coding experience, it'll really start from the basics and teach them from there. You don't have to teach them all the variables and stuff like that.
While I like the Academy a lot, it could maybe go deeper into some of the topics. The basic ones, such as Excel, which is already a decent course, could maybe go into more specifics. My issue is that, while the basics are good, getting into the weeds a little more could be very helpful. It's hard to specify exactly what is needed, however.
We've used the solution for about a year now. We're still getting used to it.
Our stability is great. You rarely have any downtime, once you build it. There's obviously the support, however, I'd say it's pretty minimal.
We're trying to work on scalability at the moment. It's there, however, we have a lot of different departments that do a lot of different things and that's where we need to really work on scaling. It has nothing to do with UiPath. It's just about getting everybody trained up on everything on our side. That said, we can see how it is possible to scale in the future. We do plan to increase usage.
Currently, we have about ten users who are familiar with UiPath. It's not too many. They are either developers or just everyday users that support it.
In terms of technical support, from the perspective of tickets, et cetera, I would say they are pretty good. We've only done a few upgrades so far. We've only had it for a year, and so far, in that time, support seems great. They have been helping us out on everything.
We did not previously use a different RPA solution.
I can't speak to the initial setup, as we had an outside party handle pretty much everything. I actually joined after they onboarded us and everything, and therefore wasn't a part of the process at all.
We have two to three people that handle maintenance tasks, on top of the AI.
We had an outside party do the deployment. It was a consultant. They did it for us.
I don't have any insights into the licensing process.
While I joined after UiPath was implemented, my understanding is the company did look into a couple of other options, just to see their capabilities.
I would advise potential new users to go for it. The Academy offers a great starting point. It's a great tool. I would recommend UiPath.
I'd rate the solution at a seven out of ten.
We use attended and unattended bots, Orchestrator, and Studio for development.
We're seeing increasing adoption of Studio because more people see how easy and straightforward it is to use a lot of the features. It helps that UiPath training is free. Our entire team, including our salespeople, have gone through the training. It's free and it makes a big difference. For the salespeople, they're able to talk more intelligently about RPA.
On a scale of one to five, judging how beneficial it is, I would rate the training a five, for sure. In fact, I have taken a lot of ideas from their training to educate my customers about RPA. When it comes to RPA, a lot of it is education because some of them don't know exactly how automation can be done. I've told UiPath that I use their training in my presentation, and it is great.
We are working with a technology company called Rammer, Rammer.ai. What the Rammer software does is listen to conversations to learn the details of what is being discussed. A third-party system is used to transcribe the conversation into text, then Rammer will learn the details without much training. It knows the topics, it understands what is talked about the most, talked about the least, how much we are adhering to the script if it's a call center use case, or if it is a simple meeting use case then it knows who is assigned what tasks, it recognizes the follow-ups, and it knows the summary of the discussion. All of this is summarized in a nice, consumable manner. So now, when a bot knows all of this information, it goes into Orchestrator, logs all these activities that are picked up by unattended bots downstream, and they trigger all those processes back. So it's a massive consumption of all of those heavy use cases.
We have not yet run automations in a virtual environment, although we do have customers who are asking for it. We are not sure if we will need UiPath's help for this yet because we haven't tried it.
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. Really, it depends on how clearly we understand the requirements. So a lot of times we are able to find process gaps, which wasn't the case earlier before we started thinking about automation in this manner. I would say the ease of use is actually dependent on some of those factors as well.
Usually, starting is the biggest challenge for most people, and I think this is because it is in a trial environment and there is a lack of documentation, with multiple people doing one part of a small subset of a task. There are these challenges and then if none of them are documented, you need to figure out the process flow. From person one, where does it go? This can change when people can do multiple things.
It becomes a very complex web to understand and navigate through. We need to understand the task and how it should be performed. For developing the robot, it's very important to have the clarity upfront, otherwise, we cannot code them. That is the biggest challenge, I feel.
From the point that a UiPath license is purchased until the first bot is ready is almost immediate. This is because we usually start with a PoC on a small scale, just to see if automation with this approach makes sense. By the end of the PoC, we'll normally know exactly how many bots are needed. Sometimes it is on us, more than the customer when we cannot estimate every process that is outside of the departments and division that we work with because we just work at finance. For example, we can't just estimate what marketing would use, and so on. That will sometimes delay things.
The attended and unattended classification and simplicity are great, and it's easy to explain to people. Right off the bat, the task performing the lowest granular entity is very clearly defined, which is something that I like.
I really like that I am able to tell the story, using Orchestrator, how humans work, how bots work, and how humans and bots work together. Orchestrator really tells a lot more than just being a simple task manager.
In future releases of this solution, I would like to see more packaged solutions.
We would like to see intelligence built into the core. Specifically, we would like to see the recognition of human to human conversations. That intelligence would be great because we have some very important use cases in that space that we are seeing. Our focus is moving closer to one hundred percent in that space, as all of our new work is related to conversations.
UiPath should offer an on-demand cloud-type model where you can get bots for five minutes, ten minutes, an hour, or whatever duration you need.
With respect to the stability, on a scale from one to five, I would rate this solution a five.
We don't see many failures, and this is partly because of our approach. We start by creating something called a heat map, which I learned in some of the training from UiPath. The training clearly explains how to handle errors. It includes which process to automate fully and which processes should be automated partially, with a human in the loop.
We start with the right approach. We understand the process and we have the heat mapping that gives us full clarity of where the exception flows are and how to handle them. So when you do that, it becomes second nature to handle those exceptions. We are pretty comfortable, and we are applying the best practices, which adds to the stability.
Talking about our own people, we have roughly sixty-five who are either developers or architects. For our customers, the number is growing all the time. The requests for training and setting up workshops for them comes to us every week, basically from different customers. We don't know the extent of automation beyond the people we work with because there are other vendors like us who are also there, so we don't have the exact number but what is refreshing to see is that even VP level or senior-level employees are interested in learning. They ask us if we can hold a workshop for their entire team, whether they're doing the development of bots or not. Hopefully, that will increase the numbers, but right now I don't have an estimate on the total number of customers. I only know on our side.
We have tremendous support from UiPath. We can say that from our perspective, we are very fortunate to be in the Pacific Northwest and that team is one of the best. It doesn't matter if we are big or small, they help everyone. So every time we have an issue or a challenge, whether it's engineering, presales, architecture, or development, we get all the support.
Our customers usually don't know much about RPA, so one of our jobs is to educate them on it to get them interested. Gradually when they understand, it moves forward.
In the majority of cases, the initial setup of this solution is simple to medium in terms of complexity. We are finding very few complex scenarios at the moment.
I think the overall architecture is simple. It is very clear and very straightforward. UiPath's product team is doing a great job in is creating a lot of very out of the box integrations and analytics, and that always helps. That is good, but I think if people are not trained yet and they think that it's easy, drag-and-drop, and simplistic, those folks struggle a lot.
We've seen that people think "Oh yeah, it's just some scripts and drag and drop so we can do this easily" and that misconception exists. We don't treat it as an easy scenario, so we gave it all the respect that proper Python code, a data science problem, or a highly complex situation deserves. When you approach it that way, it's at best at a medium complexity.
In general, we treat it right in the middle. It's not that straightforward, but the architecture is simple enough that the development complexity is medium. That's the simple and medium combination.
When it comes to ROI, for some scenarios it's immediate on the day you go to production. Doing the math, if it is automating thirty hours of work in a week, it is going to be the moment you turn on the switch.
Sometimes when the expectation is set at a different level, the KPIs are different. It may be that the customer is looking to have an "X million" dollar cost saving. It just depends on how you're defining the KPIs. So in those scenarios, obviously it'll build up to that saving.
A lot of people talk about the total cost of ownership as being a real saving or real value for products. So there are just all these different layers of complexity in that. I mean in theory it is immediate at the moment you turn on the switch, but then you need to consider the bigger picture, and it's not a straight answer. It'll be different.
The most important tip that I would share with respect to the licensing is that you should not think of a bot as being able to do only one thing. You should always consider the downtime and utilize the bots properly. That's the way you can have exponential ROI from just that one simple investment.
Even though these bots don't really cost much, you still want to say there are resources like a dedicated machine that is there, there are electricity and all kinds of resources that also go into it. So the overall cost, we should look at that. If a bot is doing ten hours' worth of work in five minutes, there are twenty-three-plus hours work that the bot can actually do. So, think of orchestration.
Some of our customers have tried different solutions. There are some customers who have even tried a lot of competing products and they're not satisfied. They have a very low expectation from what automation should or could do. So for us, that's even harder in terms of educating them.
People who don't know anything about this kind of automation, sometimes it's a little bit simpler to just run them through an hour or two of our workshop, but people who already know about it may have set their mind in a certain manner. Sometimes for those customers, the customers with experience in other solutions, are usually a little bit more difficult to convince. They have doubts that have come about because of whatever they've been using, and they don't fully understand the capabilities because UiPath does things very differently from others.
So on both ends, education is a challenge.
We are very excited about the new things that have been announced recently. There is the integration with AI, with AI fabric. There is Studio X, which has pre-built APIs with Microsoft Office and all the other Salesforce integrations that they've come up with. These are very exciting because that will increase adoption even more. People already understand unattended and attended automation, and now with Studio X being available so easily, and with analytics being part of its fabric, it's going in the right direction.
We have a very nice step-by-step flowchart that explains how to approach or what processes to automate first of all, and what are the chances of change or variations and all of that. While we are developing this, we at least are following the best practices from all the training that we received to ensure that we have taken that int consideration and we have not picked the process that is hard to automate, or which should not be automated. Then, it's more of a system change or any transformation that the customer should do first and then do automation. Basically, we should not do automation for the sake of it.
At my company, we don't work with any other RPAs. When it comes to customers choosing this solution, it should depend on the use case. If there is a strategic advance that they need to get and they need to really think of analytics and intelligent automation, UiPath makes a very compelling case. I think that it is important to choose your solution wisely and do it based on your use cases.
From a cost perspective, there is a big difference between the attended and unattended bots. One is twenty-five percent the cost of the other, which is a massive difference. Our customers use both, and we like this a lot because the way we utilize attended and unattended bots are the right way to do it. If you need to do multitasking and handle a lot of tasks, the choices vary.
Specifically from a pricing point of view, I think it is justified. When I first heard the price, and obviously I didn't ask about the duration or subscription levels, I thought it was a monthly price. Hearing that, I thought that it was cheap. Later, I was told that it was an annual fee. So for me, I understand that my customers can afford this price, and I am happy with that.
I would rate this solution a ten out of ten.
We primarily use UiPath for outsourcing. Customers call us when they need extra people to fill positions, on a temporary or permanent basis, similar to a temp agency.
The biggest use case that is running right now is that we get job openings or requests from a lot of different third-party brokerages, customers, clients, vendors, et cetera. They all arrive through different platforms. We get an email saying there's a request, please check it out and let us know if you have someone to fulfill the position, and the request is implemented through UiPath. It's automated. We've created all of the mailbox folders based on the sender and the subject, so we know which customer or which broker it is. Then, we make the email follow a link to the information for the job opening or the inquiry and we put it into our Salesforce system.
There are a couple of smaller use cases as well, where we have task operations that have to be done weekly or daily. Mostly it's reading emails or reading schedules and making changes in files.
The automation of job inquiries has a lot of sufficiency on how we operate as we used to have multiple people need to be available throughout the day to manually check if an email with an inquiry came in, and that would require them to drop work and open the email, check it out and maybe take action immediately. Now that the robot is running and taking care of the need for filtering through all the results for them, employees can stay focused on the other tasks that they have. They don't have to keep an eye on a second monitor every time and drop everything they're doing to read an email only to decide what is relevant or not.
I understand work has to be tested. It hasn't impacted the entire company yet as I've been here a little short of a year now and we haven't made that big of an impact just yet.
The most valuable aspect of UiPath is the community in terms of the way they open up their platform to the community and make it freely available for people to try and to practice. The amount of feedback from that community makes it very easy for us to get into UiPath and if you're trying something that you've never done before, you at least have some insights. There's almost always someone who has done it before or who has asked the question. I would say the community is one of the biggest extra treats for UiPath.
From a technical perspective, I like the learning curve in the Studio and in the orchestrator - or the Cloud Platform as they call it now - due to the fact that it's easy to get into. It's easy to grasp the basics and to get started. You can scale up as fast and as far as you'd like or need to for your customer. It can do everything. You don't have to learn everything in advance to be able to work with it. It makes it really approachable.
Building automation can be really easy. The biggest challenge is to find the easy use cases as the use cases in the company can get quite complicated quite fast. That said, using the recorder in the Studio and then converting that to work in a mobile office is quite easy. I started in 2016 or 2017, and between then and now there's been a lot of changes. It's always been easy for developer-minded people to get started. However, now with the introduction of StudioX, it is even more focused on the different users and they have a different entry point for them. What I like about UiPath is that the training is really comprehensive. You can almost just record what you do by hand and then StudioX will translate that into a robot and then you can fine-tune it to make it more robust. Smaller costs can be easier steps. Just press record, do what you do, and then you're able to work with teams.
Scaling automation without having to pay attention to infrastructure does make my job a lot easier for now. What I do see in companies is when they've taken the first steps and they start to scale up, a lot of them have policies or ways of working in place where they want to stick to the ways that they know. A lot of time I see customers will, in the end, do it by themselves anyway, so they use all of the upscaling functions that are available as they want to do it the way that they always did.
UiPath enables us to implement end-to-end automation starting with process analysis, then robot building, and finally monitoring of automation. However, while it does facilitate end-to-end automation, it does take a lot of the development and running and monitoring of the robots on itself. That is something that is facilitated really well by UiPath. The process discovery and the analysis is rather newish within UiPath. Maybe it's not as well integrated into the community platform.
At this time, UiPath has helped to minimize our on-premises footprint as it is a cloud-based solution. It's important that the on-premise footprint has been minimized as it makes it easier for us being a small company. We have 160 people working for us in the Netherlands and then a couple in the Caribbean. Bringing new technology in like robotic process automation and then asking from the IT department to get me free service and results of my configuring and have all the discussions about what goes where, how the security works, how to find the work, who gets access, et cetera is easy. This is due to the fact that UiPath is offered on a cloud basis and I don't have to do all that on-site work, which allows me to get to building and talking about RPA quicker.
The fact that the vendor handles infrastructure, maintenance, and updates saves time for our IT department. It helps us to implement a lot faster. The client companies can have a reliable cloud solution to help them do at least the first steps to get them acquainted with the product. It makes it a lot easier. It helps me a lot, and it helps our customers in starting out as well.
UiPath has decreased the time to value in that since it's cloud-based, I can deliver faster than I would be able to do on-prem. If we have an idea, or if we want to scale up, we can do so faster in the cloud solution than I could on-prem.
The product lowers the overall total cost of ownership by taking care of things such as infrastructure, maintenance, and updates, however, I'm not sure what would happen if we scale up.
The automation Cloud Platform has definitely helped reduce the time it takes to create automation. It brings a lot of things together. It's easy to use for clients and customers. It makes it easy to bring different disciplines together, so I don't need to think about how to reuse my code, or how to explain to the customer, and I don't need to share the processes to be able to release, run, and monitor and to get reports on the results.
UiPath has reduced human error. There are fewer errors and the processes are less error-prone and once the technology has proven itself within the company, within the customers, people start to trust the robots to do what they do. Employees don't need to check the work that had been done as they know that if the robot reported that it was done correctly, then it was done correctly. In that way, it has saved a lot of time by not having to check anything.
It has also freed up employee time. It's a three-person team and it saved them a couple of hours a week doing the work that they used to do. It saved them a lot more focus as they didn't have to monitor the email inbox all the time. They were able to apply more focus to the other things that they were doing. That said, it's hard to quantify the gains. However, overall, it has made them happy. That's one guarantee. They absolutely love that they gave the mundane work away to the robot because it was bothering them to be monitoring an email inbox all the time. It's given them the time to focus on cases that match the right people to the right inquiries or openings. I don't have any metrics on it, however, anecdotally, they tell me that it helped them to do the rest of their work better as they could apply more focus to more important tasks and placements are better attended to. There's much more focus and attention and better matches being made.
The solution has saved costs for our organization.
I'm trying not to sound negative about it as I like them a lot, however, the process mining and the process mining features stem further away from the development of the robots and the monitoring. The development, run, and monitoring are really closely knit, or really close together, and then process discovery is starting to get there. It's on its way, however, I don't see that it's as closely connected as the other three parts.
The automation operations have not brought down any company costs. Automation operations have gotten more expensive due to the fact that we added UiPath to them. That said, you do get gains at a different branch of the company. We didn't replace anything with UiPath. We weren't able to skip a step or program or tool, which makes it an added cost.
More documentation would be helpful, as they change rather quickly. There are two yearly stable releases and then a couple of community releases and data releases in between. Sometimes not all documentation is changed as quickly as the features are. Sometimes you can find something in the documentation that is not the answer, or not available in the product anymore. That's simply a side effect of how fast they develop the product.
Sometimes it's not entirely clear what features are, for example, available in their community edition, or in the on-prem, or in the cloud. The difference between the on-prem and the cloud has become clearer in the past few weeks, however.
I've been using the solution for three years now.
I started out at my previous company with systems integration. We started out with discovering robotic operations, discovering the tools, and suppliers. We chose UiPath and one of the competitors, as we found them to have the best suit with our customers. That was the end of 2016. That's when I started doing training in UiPath and started doing some custom integrations.
Now, I switched to a new job at a different company where they want to start an RPA practice as well and they chose UiPath solely for RPA.
From the operations standpoint, the stability of the cloud it's very good. I haven't had any issues with stability. The Studio will crash at random times. I've identified two scenarios where I'm able to make the Studio crash every time by just doing the same actions.
However, other than that, the automation was really stable, and I haven't had any issues or incidents. In Studio, I'd say it is good enough, however, there is some room for growth there.
Scaling automation without having to pay attention to infrastructure is a bit pro for UiPath as I'm starting an RPA practice. We don't have a lot of infrastructure engineers to build the project yet. Therefore, a lot of the time, with new customers as well, it will be a bit of a one-man show. Yet, what we can do is communicate to the platform and then make sure the infrastructure is there and then implement the platform and build a business analysis basically in an un-built realm. I have to do a lot of things by myself, so the fact that UiPath brings in the Cloud Platform and the Studio and it's all integrated and you can scale up without having to have too much. You need to know something about infrastructure to understand what it does for you, however, you don't have to do it all by hand. I don't need like three or four DP-trained individuals to be able to scale up or scale out. It's helped me get further faster.
Once you build the infrastructure and you know what you're doing and you know where you want to go with your platform and scaling, it's rather easy.
The only people really using it at this time are me and six trainees. There are a couple of ops people as well that are able to log in. We might have a total of ten people on the solution.
It's not being used too extensively now, however, that's for a large part due to the fact that most of my colleagues are working with our customers, so there are not too many internal processes or tasks. However, we do have plans to increase its priority as the tasks that we do have are at some points largely repetitive. We do a lot of operations and maintenance for our customers as well in different fields, so we are mainly looking at that for further automation opportunities.
Technical support has been pretty good.
I get a quick response and it's usually constructive. I manage to fix my own problems a lot of the time using the community forums and information from there. I haven't had too much interaction with UiPath tech support.
We did not previously use a different solution.
I personally implemented the solution at my company.
We currently have it running, so some internal processes. And, we're looking to expand that into the customer landscape.
The setup is simple. They deliver it in a cloud environment, I didn't need to do any installs or make any arrangements.
You need to make an account and get started and watch a couple of training videos that will help you through it. The adding of the robots is very well documented in the forum, in the community, and in the training sessions. They have made it really easy to get started and to get the information you need to take the first step.
The deployment question is a tough one as I started out at this company while already having a communicators subscription on my own account. Therefore, I started out using that one and then gradually shifted toward using more automated resources. I don't have a clear overview of how much time it took to deploy. It might have been a couple of weeks overall, however, I was doing different things at the same time, and I never took a metric of how much time it took. I'd say starting out if the prerequisites are in place at the company, it could be a matter of days.
Tasks such as setting up an account, getting some service, et cetera, if you know what you're doing and you know what to ask a few questions before starting, it's a couple of minutes or hours. That said, in reality, there are always things you forget or things that they didn't do, so it always takes a little extra time.
My implementation strategy was basically to figure it out as I went, which is not the best strategy, however, it was the best we could do due to the fact that the company didn't really know what they wanted to do with RPA. I was figuring out my own place in the company and then their wishes with robotics with RPA. There were a lot of things at the same time, so there was not a closed strategy other than to start up quickly, as soon as possible, get feedback, and then try again.
For now, I alone handle deployment and maintenance tasks. That will be the case until our trainees finish training.
We did not use a third-party service such as an integrator or a consultant.
We have not yet seen an ROI and have no concrete plans for any in the near future.
While I have one or two sheets from old presentations that have pricing information, they are over a half year old. I have no current insights. I wasn't included in discussions between the company and UiPath in relation to licensing.
The company might have looked at other options. However, they did this before I was hired. Ultimately, they did want to choose UiPath, and I was hired based on my experience with the product. They chose UiPath at that time as they were working together with Oracle and that company has always been very Oracle-minded.
I use the community Studio and the Cloud Platform. I take the cloud from UiPath. I'm not sure where they host their solutions. I use the automation cloud from UiPath.
End-to-end coverage is not too important to my work at this time. Maybe if they were more closely integrated, I would be able to offer it more easily to my customers. However, now, due to the fact that I often go in at the first interaction with a customer or at a company, I have to introduce the concept of RPA, I have to introduce the product of UiPath, and I have to introduce or orchestrate the Cloud Platform and Studio. What I've seen is that that's enough for the first steps, usually, the company will have a pretty clear vision of what they want to start out with in terms of automation. However, introducing the process mining capabilities would add an extra step to the start-up that we have to do and what they want to see is faster results in the early phase. It's short the time from when I come in to initiate the first value, so they can appreciate the value and start the business cases and go from there. Maybe, once they are a couple of steps further on and they have a couple of automations, then they go look at the process of task mining as they have the infrastructure, they understand what the process automation is about, and then they start to see the value process or task mining. Therefore, the end-to-end factor, for my job, for now, is not too important as I don't truly use the end-to-end approach. I do the start by myself with the customer and then we go from there. Then, in the next phase, I will build them practices and they will start to automate the beginning of the process discovery as well. There is not something that I have initially do. Once companies start beyond that first phase and the first steps, then process discovery and process mining can be really important in automation. In a later stage, it becomes more important. However, in my case, I work a lot in the early phases and haven't seen too much of the process discovery products in that phase.
Attended automation hasn't really helped us scale RPA benefits as we are a rather small company and there's only a small group that works with the product, and therefore, we haven't been able to use the assistance in the same way a larger organization such as a bank or insurance company might use it.
We don't use the staff solution yet and we have not taken advantage of the AI functionality. While I have played with AI, I haven't had any use cases to implement the AI sensor.
Overall, I am quite satisfied with the product.
I'd advise new users to start by doing instead of only reading. Start small, like finding small processes or if you're an individual, look at your own work. Find something you could do and automate that as it gives you the best appreciation of the value. Try it out in your own environment and just explore how it goes as that gives you the best insights. For me, when I started, it was a great feeling to watch your screen and watch your cursor follow the screen without doing anything.
Keep asking questions when talking to users. When translating the biggest use case into other processes, spend more and more time talking to the users and going through the processes, and defining and understanding what happens. Otherwise, it's going to cost you a lot of extra time figuring out why you've got all these weird exceptions that you didn't expect. Everyone always talks about how easy robotic process automation is. However, only once you understand your processes from a user's perspective, you'll run into a wall. It's never standardized. It's never the same. I need to warn my customers more frequently about this pitfall, due to the fact that, yes ultimately, it's very fast, but it only is once you know exactly what you want to automate and that's why most of the time it's time-consuming.
I'd rate the solution at a nine out of ten.
We are using the on-premises UiPath solution for both attended and unattended bots. At this time, we use unattended bots primarily to facilitate integration between applications, and we are not using the attended bot capabilities.
Generally speaking, we develop integrations for our core banking system, which was written in-house and running on a mainframe. It is a highly-developed system that we started using more than 30 years ago. When it was created, we didn't have the integration capabilities that exist in other applications or core systems, today. This means that in order to have external applications communicate with the core system, we need to develop integrations. Examples of this might be web services or other APIs, and that's why it takes time to do.
We have teams to do the integration, but considering that the core banking system is in Turkey and all of our teams are busy, we don't have enough resources to implement all of our integration projects. Now, for the past three years, we have been implementing bots to handle integration by moving data from the applications to the core system, and from the core system to the applications.
The biggest benefit for us is time savings in terms of developing satellite applications for the core banking system. We are developing the robotic API, and we are integrating our internal front-end applications with the core system.
Using this approach, we can easily get and set data from the core system, and we can see the results for each transition. We can learn about what happens in the core system with the help of the bots.
The amount of time that we save depends on the use case. For example, if we implement integration between core banking and the applications instead of native integration through development, it saves a lot of time. I prefer native integration versus using the bots but sometimes, you don't have this opportunity because it will take too long to put into production. Other times, you can't justify undergoing a large development process for just a small integration, so it's enough to solve the problem using the bots.
There is another use case where our operations teams perform repetitive tasks using the bots. For example, when performing the task manually, users have to take the data from one screen and enter it on another screen. We have never tried to calculate how much time we are saving in cases like this, although I'm sure that we are saving a lot of time.
People in the organization have been asking for more projects to be automated because it is easier for them. When their tasks are automated, they are more relaxed and can focus on other more important tasks, as opposed to the repetitive ones. Getting away from repetitive tasks puts you in a position where you can make more decisions and be part of the smart part of the business. This leaves the easier, repetitive tasks for the robots.
There are a lot of really useful features in UiPath including the Orchestrator and the Studio.
The Orchestrator is one of the main tools that I use because I like to help orchestrate the bots. It is the heart of the tool and it gives me a lot of flexibility to automate or manage bots that are in the field. The Orchestration Server is one of the most important features and when you perform a deep dive, you see that it has a lot of functionality. It's great.
The Orchestrator has other features such as computer vision, AI, and machine learning, and it complements the bots and the Studio.
UiPath integrates well with Elasticsearch, which is a great search engine. ElasticSearch is more capable than UiPath for searching logs. I'm filling the gap in log reporting using ElasticSearch, where I'm feeding the logs into it and then creating dashboards, or using the analytics parts of ElasticSearch and Kibana.
The UiPath Academy is a very valuable component of this solution. Many of our employees have used the courses. With it, a person who has a little bit of an analytical mindset can easily learn to do many things. If somebody is willing to develop themselves in RPA, the UiPath academy is more than enough to do so. They will understand the components that make up the ecosystem. The academy is very good, well constructed, and has a lot of labs and exercises to help one learn the system by themself without any help, and very easily.
The logging capability that comes with Orchestrator does not allow you to create smart reports. You have the logs from the bots and what's happening on the machines because you get all of this information from the logs. However, UiPath is more capable when it comes to collecting information about your processes, time saved, or process execution. They have some smart report dashboards.
The installation and initial setup is difficult for non-technical organizations.
We have been using UiPath for more than three years.
Stability is something that we should consider in two parts. The first concerns the bots and how they are running the tasks on the machines. This comes down to what kind of developers we have because if you are developing properly, and implementing all of the exceptional cases that may occur during the execution of the process, it's very good. I haven't had any issues in cases like this.
The second part is the Orchestrator, and I haven't had issues with this either. In the more than three years that we have been using this environment, including the time in production and our test environments, we have never had an issue.
We have had two or three incidents because we didn't have enough space left on the database storage, but that was not related to UiPath. Rather, it is related to the infrastructure. Another time, the SSL certification expired so we had to renew it. Otherwise, stability-wise, we haven't had any problems.
Scalability is very good, although we have not reached a point where we needed to scale the infrastructure. The high availability and scalability are two of the main features in the UiPath environment but we have not needed to go in that direction yet. At this time, we only have five bots in the organization and that is enough.
We are not planning to increase the numbers at this point because the number of bots that we have can be managed on a single node. We don't have clusters or multiple bots because of the criticality of our processes, but these are things that you can add and set up to share the workloads. Although we don't use it, I think that it looks really promising.
In our team, we have a business analyst and developers. Some of the roles for the developers are varied. At most, we have three people on a project who are working with UiPath.
The technical support for UiPath is good. When we first started contacting them between two and three years ago, the support for everybody was the same. However, they're now offering different tiers of support that require a different license and cost. There is one basic technical support, where all customers have the right to open tickets and try to solve the problems. Then, there are different support levels where you can pay extra and you can get more assistance for solving your problems.
Up to this point, all of the problems that I have had are mostly related to upgrades and installations, and they have only been from time to time. So far, I have been able to solve problems with basic technical support. Some of the problems I have solved on my own, whereas with others, I have needed a small bit of help from technical support.
I can say at this point that the support is good, although really, I haven't had any major problems that necessitated a lot of support.
We have used other RPA solutions in the past, but not to the same scale as UiPath.
The initial setup is not very complex, but it depends on the profile and experience of the person who is using it. Considering we had a great deal of deep experience in the project implementation and also the technologies, we are familiar with everything. This includes tasks like installation of the infrastructure, configuring the databases, configuring the virtual machines, and installing the robots' features.
For less technical organizations or people, it will be difficult to implement the UiPath infrastructure. In that case, they will need the help of partners.
It's not so easy, but it's well documented. In fact, one of the good things about UiPath is that everything is very well documented. The deployment takes no more than two or three weeks.
Our implementation strategy started with developing bots using the trial license. We found the bot implementation was very easy. The trial includes everything that you need to develop workflows and the bots that run on the machines. When you get to the point where you need to run multiple bots in production, you need the Orchestration server.
We did not install Orchestrator until between four and six months after we started with the trial. In the beginning, we were testing UiPath and creating some small projects. These were very easy to implement. After that is when we decided to buy the license and move the bots to production.
In terms of maintenance, it is not critical for the bots. It's the Orchestrator that has to be maintained and kept up to date. Every year, you need to upgrade your infrastructure with the latest release, so there is some annual maintenance. If it is on-premises then you also have to maintain the hardware that everything is running on.
Of course, there should be somebody responsible for taking care of the databases and general system maintenance. The operating system, for example, should be maintained by someone. All of these things are layers and sublayers on top of the solution.
If instead, you implement the cloud version of UiPath, then you can get rid of all of the maintenance. In that case, you have only the bots and the Orchestrator, which are hosted on the UiPath cloud, and you don't have to worry about anything. UiPath does the upgrades and performs all of the maintenance, which is nice. In the future, we may go in this direction. However, at this time, maintaining the infrastructure in our organization is easy and not a burden for us.
I can't say that UiPath is expensive but I can't say that it's cheap. The cost that we are allocating for RPA doesn't burden us too heavily, so what we are paying is acceptable compared to the gains that we have in the organization. That said, it is relative because it depends on the size of the organization, the budget, and other factors. From our point of view, considering our budget, it is okay but for another organization, it might be expensive.
There are some features, such as UiPath Insights, that require you to purchase an additional license. The logging capabilities are also a feature that you need to pay extra for.
While we were searching for solutions, we read the documentation for UiPath. We found out that UiPath was originally started as a Romanian company, where we are, so we figured that we would try it since this is where it was first implemented. Our tests showed that UiPath was very promising but we kept investigating other solutions.
We tried Blue Prism and we tried Automation Anywhere, which are both RPA tools. We also did some studying, looked at the Gartner report, and did some further analysis. Ultimately, we decided to buy the licenses from UiPath because it was solving all of our problems.
When you use this system, you are using features from several different modules. It's something like an ecosystem where you have the bots, Studio, and the Orchestrator. If you are not using all of them at the same time then something is missing. They complete each other. If, for example, you don't have the Orchestrator and are only running the bots then it is a different kind of automation.
In the past, as I was using UiPath, I found that there were additional features that I wanted, but regularly and with each product update, they were bringing in new functionalities. At this time, I don't have a project that is waiting and cannot be implemented due to missing features. All of the tools that they deliver, for the time being, together are enough to implement any type of project.
We are not yet using the AI functionality because to this point, although that is because we don't yet have a proper project for it. At the same time, the AI and machine learning functionality are very important to us because we are planning to use them.
We have not used the UiPath Apps feature because it is one of the new features that has come out lately, and we haven't had the time to gain a deep understanding of these technologies. We have some rough ideas about how we can use this feature, but for the time being, we do not have a project that needs to be solved with UiPath Apps.
My advice for anybody who is implementing UiPath is to start with studying the processes and trying to determine whether they are good candidates for RPA. In order to automate a process, you need structured data such that the inputs and outputs are somewhat predictable. Once you know what it is that you want to automate, you have to understand the capacity, and then if you have any candidate processes, you can begin developing.
UiPath is the RPA solution that I recommend. However, it is important to know, before purchasing a solution, which of the processes are good candidates for automation.
I would rate this solution a nine out of ten.
I am an automation consultant and most of the robots that I work on are unattended.
Some of our use cases involve end-to-end automation. One of them is an SAP system where the transaction data, material numbers, and other things are used for T-codes. Based on the value of data in the T-code, it opens other T-codes in the process and updates those registries accordingly. This may include, for example, T-codes one and two. Then, from T-code one, I need to get input with regard to my material numbers. This might be a materials invoice or the invoice numbers of material orders. With those, you have to put it in one T-code and get output.
Based on the output of the T-code one, you need to do the rest of the operations in T-code two and T-code three. Once the job is completed, update all the information about the different T-codes in an Excel sheet and then update it back to the system.
UiPath saves time both from the perspective of a developer and an end-user. I can talk about the two positions because I have been involved in both roles. On the development side, the features make it very easy and tasks that normally take half an hour can be completed in a minute or two.
With respect to the end-user, assume that a process normally takes an hour a day to complete. Once the automation is in place, the whole process will be done in a minute or two. Importantly, the user does not have to monitor the process because it runs in the back end or on a server in a remote location. The entire process will run without monitoring.
At the same time, the user will be informed. Let's say that you have to get some data out of it; most of the time, the data available every few days. Personally, given that I am not normally in the role of the end-user, I have to log in to all of the systems and look for the data. However, if UiPath is configured and developed properly then it will inform you in an email that the data is now available. Similarly, if there is no data available then it can be configured in such a way that the user will be informed of that. This would give the user the opportunity to save and plan to utilize their time for other purposes.
In our company, we have a lot of use cases where we were able to implement unattended automation. This meant that we saved a lot of time and we were able to reutilize the employees for more useful engagements.
An additional thing that we are able to achieve through using an RPA like UiPath is a reduction in errors. When we are performing any kind of activity, such as a recalculation in Excel, or calculations in a step-by-step process that involves manually copying data between two places, there is a high chance that an error will occur. This is a human error that can be avoided once we implement the automation and move it to production. Ultimately, all of these types of errors will be eliminated.
It is difficult to estimate the total number of errors that we avoid, but I can say that we were able to save time and with each process, the number of errors is reduced.
The most valuable feature is the set of data scraping tools. You can scrape data into your tables, then easily transform it or convert it between formats. If UiPath or another similar automation tool was not there, it would be very difficult to automate something that is a UI- based application. There is no other option to get that back-end data out of it. If we were not able to convert the formatting, or if for whatever reasons we cannot extract the data into a table format, it would be very difficult for us to convert and get the data that we want. The data would be difficult to format and we would spend a lot of time on it.
UiPath provides the data in a table format and in a structured manner, which means that we are able to get the required value from the table and do the necessary calculations on it. It saves us a lot of time in this process.
We have started using the AI functionality but so far, not to any great extent. For example, we were able to identify different types of images while reading an invoice. Prior to using the AI capabilities, we were not able to read them. This is our only use case for AI at the moment, but we plan to explore other activities and possibilities.
We have used the UiPath Academy courses and by doing so, we were able to learn a lot of things. They had examples of use cases that can occur in different scenarios and instead of getting that from a live environment, or during development, we were able to learn it from the Academy and a live example.
With the Studio, we can do basic troubleshooting in the production machine or VM, in case any error occurs. This is helpful because we don't have to move the data back to the development machine.
The integration with APA should be improved with respect to adding data from external sources and being able to bring in data from third-party applications. Also, it should be better the other way around, where UiPath is providing APA data to other applications.
I have been using UiPath for the past four years.
If the application is working fine, without making any updates or changes, then the bot will work as expected about 95% of the time. However, if there are any changes to the end-application made by the developers, or there is a content change, then we definitely have to align to those changes and it will take time.
Generally speaking, we move a process to production once it is stable.
We can easily scale this solution so the scalability is quite good.
We have between 15 and 20 developers in my team who work with UiPath. I am not sure about the number of people on the other teams. In terms of end-users, there are more than 100.
I have developed 30 processes personally, and my team has created more than 200. We plan to continue using UiPath in the future.
We have used technical support and the UiPath technical team is good. Whenever there is help required, and we are not able to find the solution for that from the UiPath documentation, we get a ticket with the support team. Based on the criticality of the process, they help us.
We did not use another RPA solution prior to UiPath.
The initial setup is straightforward and very easy. The main component is called Orchestrator and then there are two more components called Studio and Development Robot. These two are connected to Orchestrator, and once the development is complete, you can do the unit testing on the same machine. After this, you publish the package.
Once the item is published, it will be pushed to the Orchestrator and then connected to the bot. This is where you're going to run the process. Once it is complete the bot will start running. The whole process will take approximately 10 minutes and you can move the data to production.
When the process is running in production, Studio allows you to troubleshoot from there, without having to move it back to the development machine.
I deployed UiPath on my own. They have provided enough documentation.
The pricing and licensing costs seem okay to me, although it is a little bit on the high side.
In the past, you needed to install the Studio license if you wanted to be able to troubleshoot in production. However, that has changed and you no longer need to buy it separately.
My advice for others who are implementing or using UiPath is to ensure that they test the robots and processes thoroughly before moving them to production.
I would rate this solution an eight out of ten.
