The initial setup of Kryon RPA can be considered moderate. It is neither overly complex nor extremely easy. However, the configuration deployment and client version setup are relatively more user-friendly compared to other products.

Initially, the deployment was mostly on-premises as we explored the project's capabilities and conducted proofs of concept (POCs). This was during a period when the organization was also using AWS and Azure. However, gradually, we migrated to the cloud to leverage the product's features and capabilities. Initially, on-premises deployment was necessary for testing purposes. Now, the implementation and deployment process has been simplified, and we primarily use cloud apps.

The initial setup itself only took a few days. However, the duration of implementation and deployment depends on the complexity of the project or process being automated. Once the implementation is completed, the migration to the production environment is usually quick, taking only a few hours or days, but in some cases, it can take a few weeks.

The implementation timeframe varies based on the complexity of the specific use case we are working on.

I have in-depth knowledge of Kryon RPA and other similar tools. I have used Ui Path and Blue Prism in the past, and I find Kryon to be similar and easy to use.

I have a good understanding of all the action blocks and how to use them, which makes it easy for me to set up and use Kryon.

The install of RPA was very straightforward. The Process Discovery service install went well, but configuring it properly took a couple of iterations of calls with Kryon to ensure that we had it done right.

We had QC stood up in half a day of production, not including the virtual machines. That wasn't on our team, but the actual install and configuration of Kryon was about half a day. We had two or three calls scheduled to install and configure everything else for RPA and production.

We wanted to make sure that we had a development and QC environment, then production environment. The only strategy that we had around it was to make sure that we followed the best SDLC practices that we could, as far as testing, not coding and prod. One of our guys just set up a call, then we went and did it. 

The bot took a month or so to stand up and test, then vet with the business off and on versus the six months that it would have taken to actually build a full solution. Then, if something had changed with any of our systems, that time would have been lost. That is a big savings too, just the opportunity to use this instead of dedicating a whole team of resources to a project like that.

The initial setup was complex for us, but that was, in part, from the way we operate at LTCG. I wouldn't put that on Kryon.

From start to finish, the deployment was four months.

The initial setup was fairly straightforward. When initially setting it up, it definitely does benefit to have some IT experience in setting up different types of servers. Overall, the process itself was quite straightforward, though.

The deployment process was pretty quick. We did it between mid-March and mid-April, deploying three environments. A couple of which only took us a day to deploy. Once you are familiar with deploying the environment, it can be done very quickly.

We kept our implementation strategy basic. We have our application server and IIS instance together on one box, then we have our database server instance on a separate box. Then, we have all of our bots linked into it. They are all VMs, so they can be snapshotted, spun up, and spun down very quickly. If we do need to bring more bots online for any particular reason, it's very quick for us to do that, as well. It is a simple implementation, but it is virtualized. That virtualization gives us a lot of scalability and flexibility with where we want to go with the platform.

I would rate my experience with the initial setup an eight out of ten, with one being difficult and ten being easy to setup. It wasn't very difficult.

It was relatively straightforward, though aligning it with our security protocols took some effort.

We deployed it on the cloud. 

The cloud here means the clients reside on our physical machines, and we connect back to the cloud that stores the data. I'm not sure where the cloud is located, but we feed the data back to the Kryon Cloud.

For the setup of the whole Kryon environment I was only involved in the framework, just to make sure that our system group prepared the server and installed the SQL server they requested, and to make sure they had all the permissions they needed, but nothing more than that. The consultants did all the rest.

Maintenance requires just my colleague and myself.

I rate Kryon RPA a six or seven out of ten for its initial setup.

The initial setup took some time because there are a number of components. There is a server, Studio, etc., so it takes some time to set up properly. But once it is set up, it's easy to work with. But the initial setup requires some time.

Setting up a server typically takes three to five days. We go through a process where we regulate things, we make sure we validate the software, and we that we have approval. 

Our implementation strategy was to first set up a pilot. After the pilot, we wanted to go full-blown. That's when we looked at infrastructure for development, testing, and production. We then started bringing a lot more LOBs in, to grow and develop.

The initial setup is straightforward, without any issues.

The initial setup was pretty complex. The install is certainly not for the faint of heart. There are a lot of options and a lot of ways you can install. Given that we were installing in the cloud too, it took some time and it took some troubleshooting and work, but we got there.

It took somewhere in the neighborhood of a month for us to get the AWS environment up and running and then figure out all the nuances and dependencies of the install.

Our implementation strategy was to work side by side with Kryon and our network teams and get it installed. They gave us some initial pre-reqs and things to install and things to look at. We were one of the first to get everything operating in the AWS environment, so there were some specific things to us that we had to figure out on our own.

For the deployment, we had the equivalent of one dedicated person for a month. And we have the equivalent of two people maintaining it. They are RPA developers who work on setting up RPA jobs and configuring Process Discovery, etc. We have five users in total.

We had somebody within our department doing the initial setup, although I was on the calls. It was a little bit complex, because there were some issues we ran into with Server 2016. When we tried to run an unattended bot on there it wasn't working so we had to switch operating systems. We've had to go back and forth to get things truly set up and ready to go. We're still working on the deployment, but that's not necessarily because of Kryon issues. It took some time to figure out the issue with the server, going back and forth with screen-sharing, etc.

And it seems that the size of the virtual machine that they provided with us might not be enough. We're trying to figure that out. Chrome keeps crashing on us. Once that is resolved, we have three or four processes that are pretty much ready to go. I just have to get through the actual testing of the running the unattended bots on the virtual machines.

In terms of an implementation strategy, we are working with our shared services teams to identify the processes. We have a daily “stand-up” and a weekly planning session to figure out and prioritize our processes. Then it's just a matter of building and testing and getting them out.

Setup for Studio and Robot is pretty straightforward. We have to install the Studio and Robot on the machines, create accounts for the users and assign access rights. Then login Studio to develop wizards and Robot to run the wizards.

On the technical side, the setup was done mostly by HMS. The issues we dealt with were mostly to do with the connection to our organization's system. The authorization issue was difficult for the system and many other aspects, but I know part of it was from our side. We also had some information-security issues. I don't think it was too complicated, but it took us about a month-and-a-half, to do the first at set up, and then it was much easier.

We learned a lot. We learned what we need to prepare for each process so the process will be the most effective and quick. We learned about the abilities of the tool and that helped us in thinking about the next processes and how to do things more efficiently.

We are also using BI to help us with more complex business logic. Instead of doing it in the robot, we are doing it in BI and giving the robot more direct reports to work on. It makes our process much smarter and efficient.

In terms of deployment and maintenance, we have one full-time employee working on it, and one of our business persons, a project manager, is working on it half-time. He's involved in building the business process, deciding what will be the next step, and helping close all the details on our side.

The maintenance is not high. It's just that each time the system is changing, we need to teach the robot the process from the beginning. This is the only maintenance we have. The other work is really to in developing the next process each time.

The initial setup was straightforward. It was very quick, very understandable, very open. If we had problems, they were helpful. They assisted our third-party company. It was very easy to work with.

Deployments depend on the process. We have been working with the system for a little less than a year. After about two months, we had the first process working. It's really quick. When I say two months for the first process, that means we sat with the customers, understood what they want, how to do it. We had them test it, we launched it, we optimized it in production. The whole timeline of the process was handled in that amount of time.

We asked our organization to set the priorities. We asked for a quick win, meaning something very small and very painful, or something which was taking a lot of time. That enabled us to win their appreciation and reduce the resistance to change. Some people may look at it as a robot is replacing me. We handled this too by making them a part of the implementation process. This way, they wanted it, were engaged with it, and wanted to do more. It gave them something that they hadn't seen before. It gave them a feeling of success. It's very important, through the process, to feel like you are succeeding in doing something new in a very short amount of time. The people involved have to see we're not really replacing them, and that it actually helps them to do more, to do better, to do things that have work quality to them.

The people using Kryon are from three departments: collections, services, and operations. Not everyone is using it, because we're uploading files to the system. There a few people in each department who are doing it. Overall there are about ten people involved with it, but it services the whole department. There are the people who operate the system, and the people enjoying the fruit.

The initial setup for Kryon RPA is very easy, and if you compare it with other RPA software, it's easier.

The initial setup was a little bit complex because Kryon needed to obey bank regulations. We have very high security requirements. They were very devoted to solving the issues and it was great.

The deployment took a total of about three weeks. 

Our implementation strategy was done in a spiral way. We started with a single process. It took us two months to install the system, get the knowledge we needed about it, and to analyze and develop the first process. This onboarding process was accompanied by Kryon Customer Success. In the beginning, we had a kickoff meeting and we decided on a day, two months down the road, on which we would have the first process in production. We worked together to make it happen. And we succeeded in achieving this goal. Then we started to analyze two or three processes in parallel, and we continue to develop and analyze the next processes.

I was not included in our initial setup. That was done before I was brought onto the team. But I am familiar with upgrades. 

The first upgrade that we did was not fun at all. It took seven or eight hours. The second time, when we upgraded to the 19.1 version, it was an hour-and-a-half, both because we got better and because they provided better documentation. We also got a QA environment, which we didn't have before. When we installed our QA environment, I don't think it even took half a day.

Part of the difficulty with the upgrades was that we didn't know any steps that we should have taken, because their documentation wasn't step-by-step. So we were on the phone with them, walking through the upgrade the first time. We missed steps because the documentation wasn't there. But the second time, the documentation was great. We knew exactly what to do. Our app engineer had all the setup stuff done before we had our meeting with Kryon, and we just walked through it. It was awesome.

There were two of us, from our organization, involved in the upgrades. Kryon had people on the phone but they weren't doing anything. They were just watching us.

In terms of maintaining the solution, there's one person who handles all the bot servers and there's one admin on Kryon but he's super-part-time. It takes maybe five percent of his time. I haven't had to talk to him for weeks. And there are two of us on the team who handle the support and the bot building. There are six departments that we have built bots for, and I don't know how many people are in those departments, but they don't handle anything with them. They don't have access to Kryon. We handle everything.

The initial setup was deployed by Kryon.

Our implementation strategy was evolution strategy, process after process, and be the leading business user.

The initial setup was straightforward. 

The deployment took a couple of days: One day to set it up and one day to review.

We just have one environment with multiple bots. We straight away went into production. We didn't have a testing environment or equivalent.

The initial setup took a while because we're a bank, so we have all the security requirements. It took a while but the setup was not very complex. The go-live took a couple of weeks but that was not entirely because of Kryon. It was due to the bank system itself, the firewalls and security.

Our implementation strategy was to go to the back office. We took ten nominees and we tried to pinpoint the one that would be most useful yet which was not too complicated. We gave it to Kryon as a PoC. They came and we said: "Let's take it step by step. Let's see if it works." If it did, we would try another one. We would then try to spread it among our core systems. We would connect it to each core system and have at least one active job in each of them. From there on, we made set up a center of excellence within the bank for automation, and people come to us now and ask us.

The setup was very straightforward. Kryon dialed in remotely and did most of the work, along with our infrastructure guys. There were no issues there. It was really smooth.

They did it in sync with our guys. We had someone with the proper access and rights, so if they needed to do something on the server, for example, we had an engineer with admin rights on the call and able to assist them remotely. They worked closely with our lead engineer for IT to get it in and there were no issues at all.

The installation itself was just hours, literally. It was really quick.

It's the same with upgrades. Upgrades are very smooth and they don't take very much time at all. Kryon staff do the updates as well.

As far as the installation of application goes, there was no strategy. We just followed the steps in order.

Where implementation of robotics as a program is concerned, the strategy was to get some low-hanging fruit, some easy jobs with high ROI, and try and to show success. With that success, we rolled it into buy-in from the rest of the teams. Something else we did as a strategy was that we put a developer in each one of the departments, so it wasn't someone from IT doing the development, it was actually business-users. That way, people's peers would be designing, implementing, and developing whatever is being used in their departments. We got the subject-matter experts to actually design their own jobs. They chose what to automate, when to automate it, and then they would automate it themselves. It wasn't "Big Brother" pushing things on people. What they wanted to automate, and when they wanted to automate it was determined within the department. That created a better buy-in for implementing change and for change-acceptance in departments.

People always have their backs up against the wall if it's someone forcing something on them: "Oh, now you have to use this application." The response is often, "Well, I don't want to."

This way, it was them and their peers deciding what they were going to automate. It was much easier to get their buy-in. They determined as a group what they wanted to automate. It created a better culture for change-acceptance.

It's hard to say whether the setup was straightforward or complex. I think it's quite simple. But because of all the security requirements for data at our bank, we couldn't do it in a straight way. We had to go a very different way, so it wasn't so straightforward. I don't know if it's our fault, because of all the security issues we have, or if it's a product fault. Let's put it at 50/50.

It took about a month-and-a-half, from the beginning of the deployment with Kryon, until we solved everything, and we could run our first process in a production environment.

Our deployment strategy included internal meetings, trying to map the processes we wanted to automate. Second, we started negotiations with Kryon for buying their product. Then we started learning the tool and how to work with it. At the same time, we started installing it on our server in our company.

After we finished the basic installation of the development studio, we started developing our processes. That was the month-and-a-half. We were installing the program and dealing with all the security issues. And at the same time, we mapped our processes and development.

After we finished with them, we continued mapping and identifying the other processes in our company. Kryon has been advising us, not only about installing, but also by giving us best practices on how to map and how to identify the processes that we can automate in our company.