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.
We have been using this solution for just over a year.
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.
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.