What advice do you have for others considering Kryon RPA?

Overall, I would rate the solution an eight out of ten. I would definitely recommend using this solution. Decide what you need from the solution. It's not generic. So understanding the purpose why you're buying this product exactly.

The reason we selected Kryon RPA was because of the automation capability of the process discovery. It's a little bit immature, but the new release will fix a few bugs in the product. The product has the potential to speed up the discovery process. The new version will overcome some of the solution's limitations and make it a better product. The automation capability or the RPA aspects of the solution are pretty much the same as what I've found in most RPA tools. It all depends on the environment you're integrating into. Kryon's gone through some changes because they got acquired by Nintex. In that period of acquisition by Nintex, it's been a bit uncoordinated in terms of support and other things. But Nintex is getting its act together and integrating the product into its portfolio. That's a natural thing that happens following an acquisition. Overall, I rate Kryon RPA a seven out of ten.

I would give Kryon RPA an eight. As a developer, I find it easy to use. The codes are written in a language that is understandable. They also have documentation available on their website that explains how the tools work. The way the tools are built is simple to understand. The steps can be split into different parts, and there can be more than one step for a particular bot. The fundamental aspects of the process build are easy to understand. Additionally, the build has current and account notes explaining what each step does. Overall, Kryon RPA is easy to understand, which is why I gave it an eight. I would definitely recommend using the solution.

I have experience with Kryon RPA for many versions, such as 19.3, 20, and 21. I'm a developer who provides services to clients, so I develop and create tasks in Kryon RPA for clients. Two professionals take care of the deployment and maintenance of Kryon RPA. One specialist deploys it, and the other person is in charge of the IT infrastructure. My advice to others looking into implementing Kryon RPA is to deploy in small blocks that can be reused in many jobs or many other tasks. My rating for Kryon RPA is six out of ten.

I Kryon RAP 10 out of 10. I recommend starting with easy processes. You should discuss the processes with the client, and go over things like cost, tools, time, and other things that are critical for the business.

Spend time focused on standing up your center of excellence around the solution. Kryon gave us some great advice on that in the sales process regarding defining what we're trying to do with it. Get key sponsors and then get a key team that works through the implementation, together. What we're learning from using the solution and what we're really still trying to figure out is what is a good candidate for an RPA process, versus the other ways we could automate, whether it's process elimination or deploying some of our core engineering teams to write different tools. We're still trying to figure out what the framework is for picking the best processes. The processes that lend themselves to RPA are processes that are highly repetitive, high volume, low-judgment types of processes, where you can write down the process in a Word document, write down the logic, and then turn that into an RPA solution. We haven't been able to make that leap yet, in terms of Kryon's full cycle of automation from the discovery of our processes to turning on the automation and scaling it up, but we see the potential there. We haven't quite gotten to that point yet, given how early on we are in our journey. When it comes to using the solution, for both business users and developers, you do have to have some technical background to use it. It's unlikely that you would deploy it to somebody who doesn't have any background in it. But people who are somewhat technical have been able to use it pretty successfully. I would rate Kryon at eight out of ten. It has a lot of potential and we see that potential. It needs a few more iterations for me to bump that score up higher. It has been a good experience so far and we're looking forward to the future.

The biggest lesson we've learned through our time using it is the .NET component for scaling. One of our biggest lessons is to use that wherever possible because it makes things so much quicker. Also, if you look at some of our old bots that we built versus some of the bots we build today, it's crazy that we even knew what we were doing. The process flows and understanding what can and can't be bot-able, have gotten way better. My advice would be to have a team. Make sure there's a developer so you can do plug-in things and make sure that you understand the setup and the admin tool. That was a huge lesson learned for us, going back. The way we did the setup was incorrect so we had to re-record all of our bots the first time, and that was a disaster. We didn't have it set up right because nobody told us how to do it. We didn't have that support at the front-end, for the setup pieces, for everything we were doing. And always have a QA environment first. We did not have a QA environment. When we first went live we didn't know it was an option, and I don't know if it was an option at the time. I imagine it's standard now. We have a QA environment now, but we don't have any data set up or any automation to set data up so we can't test bots in QA. We have to test them in production because we didn't go through that work. Testing was a mess. That's no longer true for our current bots, the ones we're building today, but it was a mess for all of our old production bots, anytime changes were needed. So always have a QA environment or a Dev environment. It's been hard to get it off the ground. We have a really small team, so there are not very many examples. We have quite a few bots that have saved a lot of time, but I know that we could have way more. We just need a team, and I think we're going to get one, although not right this second. Kryon hasn't helped our workforce embrace the digital transformation of our organization because we only have that small team right now. People are seeing things and say, "Yeah, that's awesome," but we can only move so fast because we're so small. So people are not super-excited about it yet. They still need more exposure to it. We have about 15 bots in production right now, but it's pretty much focused on one section of our organization, and we're a huge organization. We have plans to increase our usage of the solution. There's a whole new process improvement team coming. Once we get out there more, I'm sure it will expand. The Kryon Process Discovery is not included in our license right now. We just haven't done it yet. We've looked into it but we haven't done it yet because it's pretty complex. With the version that we saw originally — it might be different now — when it first came out, you needed special computers for it which we would have had to buy and deploy for the users who use the processes. It wasn't something that we were going to do at the time. It's not something that we have thrown off the table, but at the moment we're not using it. Just learning what bots do, what RPA does, what I can and can't do, has been part of it. I can go to any business unit, now that I've built bots, and say, "Yeah, I can do that," or "That's not a good idea." I know exactly what I can and can't do in Kryon. I don't know if any other tool can do things better because I've never seen any other tool, but I know what I can and can't do in Kryon. The original training that we got was a week long and we were trying to build bots in that same timeframe. So we didn't get a whole lot at that time. When we took their training classes online and had them come to us and train us in more in-depth, it helped a lot. Everything that we do use, that we know how to use, works nicely. I love it but I'm not going to give it a ten out of ten because there are issues. I would go with an eight. They've gotten so much better at all their stuff. The tech support was part of our issues for a long time, but it has gotten a lot better. They're getting all the training classes online and they keep those pretty updated. They have a community now. They're learning and growing and they always ask us for feedback on every aspect. They put that in their backlog for future prioritization. They're listening to us.

You do need someone with some development knowledge. Not necessarily everybody involved has to know development, but as a resource, it would definitely be important to have. A straight business-user who isn't strong in IT or development wouldn't be able to do half the things that we've done. Having someone with a development background, at the very least as a support person, internally, is tremendously valuable. As for saving time when launching new automations, we don't have anything to compare with because we didn't have an automation solution beforehand. It's new to the company. I would say our developers have gotten more proficient, so we've become quicker at development. As far as the launching now, though, it all takes about the same amount of time. Regarding business users, with no technical background, it definitely can be used. We have users of all levels of technical skill. Business users can create some basic jobs, but there are some limitations to the product. More technical users can get around the limitations using scripting with JavaScript and the like. If people are familiar with that, it definitely makes the development phase much easier. It's totally possible for business users to use it. We've had users who have done basic jobs, but when it gets to more advanced things or quicker ways of doing things, a little bit of development knowledge goes a long way. For deployment, maintenance, or upgrades of Kryon, there are two of us. I'm involved in coordinating and our lead IT guy works with whomever they assigned from Kryon. I'm not even necessary for those tasks. Really, just one person is required. I do the change request. I take care of the bureaucracy and the red-tape approvals and the like. Once all that's done, we hand it off to the technical team and there's a single person that does it all. He is the IT lead. As needed, he'll pull in DBAs or whoever, if the situation calls for it. He coordinates with his team.

Take your time. Don't rush it. Ensure that you have a few good use case scenarios to start working with, because if you don't have something to work on right out of the gate, the system will just be sitting there doing nothing as part of the evaluation. You should know a handful of processes which are good candidates that you can use as initial proofs of concept just to make sure that it will fit your needs. You want more than one, so if you do move ahead, you actually have some work to do. Kryon is easy to use. Somebody who is not tech savvy at all might have a bit of trouble picking things up. However, if somebody is a power user of Microsoft Office or familiar with the workings of macros, this is a platform that they will pick up easily. Even if somebody is not overly tech savvy and they are at least curious or willing to to read about things, working with the commands and interface can be easy. So, if they are reading up on how to go about doing what they're doing or reading about the commands, then they will pick up the system up well.

It is a good solution if you're not using any virtual machines, like Citrix. It would be better if you get a demo or automate a simple task using Kryon. Get them to show you a proof of concept so you can understand what other challenges that you will have rather than blindly implementing it. Definitely, get a demo to see how efficient it is. Seeing it in action helps a lot. We are not completely moving to a digital transformation. Even our management doesn't agree with 100 percent digitized solutions. They still want some level of human involvement, as well as for auditing. The humans in our company have been concern about the robots taking over their roles. The robots take up most of the redundant tasks and focus on those. This ensures that our agents do the more complex ones or the low volume drivers. The agents do all the ones that require more logical reasoning, installation processes, or secure processes. We train our agents on these tasks and reassign their skill sets. We give them more training, giving them more complicated tasks. We aren't trying to lose our agents, even though manpower reduction is there. We just trying to retain them, but for different types of tasks, ones that require more human involvement and thinking. We don't use Kryon Process Discovery or any of their web related services. Automation takes up most of the walling that we get from our clients. Ground is being used extensively. However, the limitations are caused by Citrix, which is making us rethink our strategy sometimes as to whether we will be able to increase with the product. We want it to be faster and more reliable. We want to ensure that with any errors which occur, it is able to identify those errors, and it's able to rectify them or at least log of them. We want to take a look at them or notify people. Currently, only because of the Citrix issue, we are constrained. We might need to take a look at another software that supports Citrix more efficiently. Currently, there's no plan to increase usage, but it is part of our major usage as of now.

I would really recommend the tool. I definitely see a lot of value with it. Just in the few release notes that I have read for some of the versions they've released since we installed it, it sounds like they are still adding a lot of features and functionality. We are very excited to get this upgrade under our belts and see what new things the new version brings to the table. It has been a great value-add for us personally and easy to use. We are happy with what we bought. No buyer's remorse here. The biggest challenge that we have had isn't even with the tool. It is with the business funding it. Make sure you have a good funding model set up for funding. Our model is fine if we could actually get more funding for it. That would be the biggest thing. If we could get the business to get behind it a bit more, giving us one or two headcount to really go after stuff. While it is a pretty simple tool to use, keep all the management centralized in IT, e.g., the operations side of the robots and keeping production access limited to a Kryon administrator who sits in the IT function. That is something that we have done really well. It just helps the stability of the bot. You don't have to worry about anybody going in there and poking at production code or breaking a process. If we did it again, that would be something we would definitely do. Once again, the challenge with that is you need to be able to fund enough people to do that. We haven't had a lot of challenges with the tool.

We have a lot of people coming to us to learn from our process, so we've been providing advice already. First of all, it's important to do a very smart business analysis, from the business side, and not automate exactly the way it was done before. Really think about ways you can improve and make the business logic, the business rules behind the scenes, more effective. This is very important. It's also important to look at becoming independent with the solution from the beginning. We have only started to plan for that now. The authorization issues within our company also took a lot of time, so I would suggest getting those dealt with in advance. Part of the difficulty in embracing the tool is on our side, due to bureaucratic issues that we have in our organization. Every change we make which results in a new version of the system the robot is working on means we need to teach the robot from the beginning to do the process. For example, when we would have a new version of the system, we would ask our people, "Has anything changed?" They would say, "No. Nothing is new." Only after would we find out that something moved from the right to the left. Just one button. For the employees, it didn't matter. For the robot, of course, it does. And then we needed to teach the robot to do it again. So we have learned to prepare ourselves better before a new version is released. We receive all the screens. We teach the robot to do everything again. We're checking ourselves. We test more. These are things we learned along the way, "on-the-job learning." We wasted a lot of time on this because we did not prepare for it properly. In terms of the prioritization process, we are working with a business analyst to decide exactly what the next process should be, what has the biggest number of activities per month and that the business case is important. We also look, from an implementation point of view, at whether we can do it. Is it accessible for us and not something very complicated which will not be possible? We take all of this into account and we decide which process to put in next. We already did the main business area and now we're continuing to another business area and doing the same process. One of the things on our roadmap is to optimize part of our monitoring processes. From a business-analyst point of view, we are using a lot of analytics to make it very smart and efficient. So it's not saving us money in business analytics, it's the opposite. But it's worthwhile for us. The discovery process in our methodology is very important because each case is a little bit different, so we need to find the right rules, the logic. The first process was the most difficult. We needed to learn how to work with it. But by using it more and more, we have achieved a very easy and quick process. The delivery time, now, is very good for us. We are adding a new process every two weeks. Now it's good, but the first time was more difficult.

Understand that you need to have a very well-documented framework of what you plan to automate. Not necessarily the idea of, "I want to automate this task." But, as a company, don't be narrow-minded to believe that these are the only tasks that we can automate. You'll find that there are a lot of groups which are doing things that you may not know of that you can automate very quickly. Be very open-minded when you start working with the solution, because you'll find that a lot more doors are open than you originally anticipated. As with anything in software suites, you are always going to have challenges where people didn't know something was a function or didn't know this is how that worked. Kryon has a good start in trying to bridge that gap between the developer, who would look at something, and go, "Yup, I can pull a lot of this data from SQL, and I just need to click these buttons," versus someone who doesn't have a technical background. There is still some growing to be done. It is necessarily the product that has been the problem. It has been necessarily some of the responses that we have gotten from Kryon itself.

The solution is easy to use. Although I felt the solution is a little restricted sometimes as I could not call any external libraries, I am able to use the advance commands, which are the built-in functions in Kryon, to program the RPA solution by changing my initial idea. It makes me think out of the box and test how good my logical thinking is.

It depends if you are doing it by yourself, with your employees or, like us, through a third- party or someone who knows how to work with the system. If you're doing it through a third-party, there is no problem and they have all the knowledge, all the data, all the know-how about how to do it. If you are doing it with your own people, training is mandatory and Kryon has it. Some kind of on-the-job training, or some kind of support, is necessary to be able to implement it quickly and the right way, because there is a right way, a way to do it properly. Kryon was not involved in helping us find and prioritize processes that are ready for automation. We did so. They were not part of this process. We came up with the processes, we talked about them, not Kryon. I'm not the one who uses the system every day. I'm not the one who uses the customization. We go through a third-party which does all the customizations for us. I can't tell you which part of the system I enjoyed the most, or what I'm using because I have a third party for that.

Make sure that you have your processes in a good place and that you have them written out. Make sure that you have your stakeholders onboard. And make sure that your bot works on the right server. We don't use the process-discovery functionality of the tool. We're identifying our own processes by polling various stakeholders to see which processes make sense to automate. But it seems like it's pretty easy. We've hit a couple of snags with our virtual machines and the OS they are running and with the Chrome Extension. We're doing everything with unattended bots since we're primarily a Mac-based company. We're not able to run them on people's local machines other than the machine I use to create the Wizards. In terms of operational efficiency, it might be a little too early to tell because we're stuck right now. But in the big picture, not only are we identifying processes, but we're also figuring out how to improve the processes, whether somebody is currently still manually doing them or a bot is doing the improved process.

We would recommend it. We don't use Kryon Process Discovery.

My advice is to follow the right set of instructions and best practices, even before you implement automation. Look at what is available, at how you do it. If you don't follow those instructions, you may find it difficult, but once you know exactly how to use it and what to do, it works. Have training properly done and after that start looking at implementation. It's really good for end-to-end RPA. The way we work is we do a discovery manually rather than using an automated discovery process. Once we identify a process and we run through a complete lifecycle of it. We then work on the design elements, how to run the exceptions, etc. We make sure that UAT is done, that it is tested well. We then make sure that the business users accept the process, how it's going to work. We then validate the bot, make sure we get a sign-off from them, and then we go to production. We do one week or two weeks off thorough checking on production to make sure there are no exceptions or issues. We then hand it over to the client to run it. In terms of the ease of use of Kryon for business users with no technical background, that's a key area. What we say to them is, if you're not familiar with Kryon and you want to automate, there is a basic, fundamental, one-day workshop. It will give you at least an idea of how to record, what the options are, what you should look for - the key things to learn about some of the elements of the Kryon platform. Then they're good to go. I see that users are then happily recording things and playing them back. So Kryon provides ease of use where they are not really struggling. If somebody knows Excel, that person can easily run Kryon. We have business users and we have some developers. It's a small team of five to eight people, including the business users. In terms of deployment and maintenance of Kryon, we currently have a very small number of processes. There is an agenda to grow big. We're looking at more than taking more 30 live so we are bringing in external consultants to help us do that job. We want to keep a lean team right now, because once we go live we will need to do more of the production support and maintenance of the bots. We will only do small-scale development in-house. If it gets to a complex level, we will get a team of consultants to help us. In terms of infrastructure, we have one guy dedicated to that right now. I would rate Kryon at seven out of ten. There are the migration issues and they need to support web-based apps.

There is a vast field of RPA tools. You have to know what you want to do and how to add value to your business. You need to see if what Kryon gives you is the best fit for you. For us, as beginners in the field, it was good, because of the support and the willingness to help us and to be cooperative. That was very helpful at the beginning. So you have to evaluate which step of the RPA lifecycle you are in. I can tell you more, in a year or two, if I'm satisfied when I am more advanced. But for starters, it is a good decision. In terms of using the solution for the full cycle of automation, from the discovery of processes to turning on the automation, and scaling it up, it's a little bit early to say, because we don't have a lot of experience. And I can't compare it to any other thing that we have, because we're really at the start of it. But so far, it has met our expectations. I didn't think it would go as fast as they described it, and it didn't, but it was fairly rapid, and it has its ROI. All in all, good. It's not for end-users, absolutely. It's not that. For developers, it is interesting. We didn't actually use developers to work with it. We had more, what I would call an "implementation guide." It takes knowledge and it takes time. There are a lot of technical issues, not only because of Kryon but because of our system and the integration between Kryon and our system. It's definitely not for end-users, regardless of what anybody says. It's not. But it's fairly decent for developers. We have our four developers who actually touch Kryon. We have two-and-a-half to three people who are dedicated to deploying and maintaining it, and another one comes and goes. We definitely have plans to increase usage. At the moment we do about 1,000 transactions each day, but we want to get do more. As for helping our organization embrace digital transformation, we're heading that way. It's only the start, but we have a good vibe here. I could answer that question more comfortably in a year. But I see the way. I see the light. We had an outside advisor, not Kryon itself, to help prioritize processes that are ripe for automation. We preferred it that way. Maybe Kryon could have given us that service, but we preferred to take an outside advisor. I would rate Kryon at eight out of ten. It's not as rapid as they describe it and it has its limits. We have met with Kryon a couple of times. The guys were very helpful and said, "We'll bring that into the roadmap," etc. But we hit the limit of the product. For starters, we expected that to happen in year-two or year-three, not three months after trying it. But all in all, it has been a good experience.

We haven't used the Process Discovery from Kryon yet. We started with processes that we analyzed and found to be suitable for automation. We find that the product, the Kryon Studio, to be very good at doing task automation. We are now scaling out and going to new processes. The decision we made to develop the processes by ourselves with our team was a very good decision. The onboarding process along with Kryon's Customer Success - if you work together with them and consider them as partners - will work very well. Regarding the solution's ease-of-use for business users, we use unattended automation so business users are not part of the process. For us, businesses users do not interface with the system. In terms of finding and prioritizing processes that are ripe for automation, Kryon offered its service in analyzing processes and finding the right candidates for automation. But we were working with a consultant from Strauss Strategy. We are working with them in finding the processes. We have a center of excellence team which contains two developers and there is a team leader who is responsible for RPA and for other tasks which are not related to RPA. So we have about two to two-and-a-half persons working with Kryon.

I would highly recommend getting a commitment from the vendor - and not only from Kryon. It's hard to get the vendor's commitment and to know, when you sign the agreement, what the SLAs for dealing with your problems are, and how committed they are to you as a client. The second thing is that more important than the source of the RPA solution is the way your company handles the automation of processes. It's a very big issue in a company. Employees are scared they will lose their jobs. It's something you have to deal with no matter what the RPA solution: how you manage these changes in your company. Kryon and others have a very methodical way to do this by creating a center of excellence, etc. It's very important to do this even before you choose your vendor. You need to address peoples' fears, that's the main thing. A good organization will not send people away, but will find them more valuable things to do, instead of the very routine things that RPA can do instead of them. You have to address many people at many levels, that this is something that you have from now on. Every new product, everything you have, they should know that you have an automation tool that you can use. It's very powerful. It's helping make things more accurate and faster. It's a change, not just because people fear losing their jobs, but in many other aspects. Even management has to know about it, about the capabilities of these tools. The users are developers. We have two developers and I am a system administrator. This program is for developers who develop the processes. Once the processes are developed, we can replace business users in certain jobs. The three of us, and perhaps two others who are administrators of our VM machines and who deal with security issues, handle deployment and maintenance.

Take the training course. At least the person who is going to program the robots has to have some background in information systems in general and in more specific, operation systems, in programming and in Office, of course. He has to have a technical orientation, database knowledge would help him, as well as system analysis capabilities. In terms of ease of use for business users, the only users are me and 2 other persons in the information systems department. Currently, we have only unattended implementations and no attended implementations which would require a user in the organization to operate it. As for programming it, it requires up-front training. The e-learning, at least at the time that we started working with Kryon, was not enough. Just the basics were there. When we tried to do some more complicated stuff, we had to understand it better. We took the four days of training. After that we started all of the implementations. As for helping our workforce embrace digital transformation, I wouldn't relate Kryon to that, at least not yet. We are still not using it for digital processes or a digital environment. But we plan to do that in the upcoming weeks. There is a process to create a new customer, which today is very complicated. The last part is to just type the customer's details into the system. I'm thinking of using Kryon which would complete a fully digital process. In terms of my rating of nine out of ten, there are many things that I'm not sure of. For example, it takes a while to launch the Studio, something like a couple of minutes. It could be that my laptop is not strong enough. It might be that our virtual server doesn't have all the necessary memory or CPU capabilities. It might be many things, so I don't want to say that it's only due to performance issues with Kryon. We found a bug in a database trigger with Oracle Database. I know that it works mostly with the SQL server, but we are using Oracle, so that's another issue that came to mind. The fact is that we found this bug something like six months ago and it's still not in the new version. As far as it was communicated to me, it will be part of the next version. If that bug was critical for us, maybe I wouldn't have rated it a nine; maybe it would be a six or seven or eight. But, luckily for them, it's not highly critical for us. I don't know how they prioritize bug-fixing. I suppose that there are not too many Oracle Database organizations among their customers, at least not in our market. Therefore, maybe they prioritize this somewhere at the bottom. But for us it's a bug and we cannot use this functionality, which is required. That's why I took off one out of ten. Besides that, it works, it's stable, it has nice performance, and was, therefore, a good decision to go with it.

No.